Resolve Feedback Loop? Attempting Ping-Pong Loop Playback

P-box · 2024-02-21T18:58:22+00:00

There was an error rendering this rich post.

Hi Builders,

I am attempting a very crude method of creating a Ping-Pong sample playback.

I wanted to test the theory with forward play which then reverses.

I am attempting to toggle the (on/off) reverse button with data from the sampler.

When I route the data from a compare module, which toggles a 0/1 based on the position playhead of the sampler, to the reverse input - which expects a 0/1 based on the data sent by the original reverse button, I get an Event Loop warning.

The sampler will play, without resolving this error, but the playhead direction does not change, as it should if the reverse button were toggled.

Any clues?

Ultimately, I would like to build this ping-pong looping feature in core, but have been surprised that in the months of reviewing the User Library, I have found only one Ensemble that has Ping-pong looping, and that is Ignasi Alvarez Garriga's "Live Audio Looper":

www.native-instruments.com/en/reaktor-community/reaktor-user-library/all/all/all/468578/

With my inexperience with Core, and his module being a live looper using a buffer rather than sample playback, I cannot yet reproduce the code to function in the Loop Sampler.

Any tips on how to resolve the feedback loop?

And any other examples in the user library anyone knows of that use Ping-Pong loop playback? I've dug pretty deep, but I could easily have missed one.

Thanks!

--Paul

Ping Pong Loop Sampler #1.ens

Find more posts tagged with

Comments

colB

https://community.native-instruments.com/discussion/26874/resolve-feedback-loop-attempting-ping-pong-loop-playback

That feedback loop only involves things that are already inside the core cell. Why would you even try to create the loop outside the core cell?

You can easily 'fix' it by including a unit delay in your feedback loop, but to me that looks like an unnecessary botch. Stop being a scaredy, do it properly inside the core cell. Core is not difficult!

P-box

Hi @colB,

Thanks for the encouragement. And thank you for being one of the driving forces behind this forum!

I am actually trying quite hard to grasp core, and am working with it an hour or more each day. It is a very new environment for me and I have no prior coding knowledge. I like to think of myself as a smart gut, but this has been very humbling!

Here is what I've come up with in core: (See Ensemble Below)

This is based on Ignasi's "Live Audio Looper"

Also note the 4th screenshot "pp looping" macro, the first math component "equals" on the left has 3 and 3 as constants. The top 3 replaced a "Mode" quickbus which selected between the various play options in Ignasi's Looper. I just replaced the Mode connection to 3 so it would read true and always run the code.

I created 2 sub macros within the PingPong55 Macro: I used Ignasi's Index code to define the loop points, and used the code specific to his ping-pong loop mode in the Macro labeled "pp looping code". Using the Wire debug mode, the numerical data climbs and falls from the LS (loop start) to LE (loop end) which he labels Win Max (LE) and Win Min (LS). In this context it works accurately.

But taking the PingPong55 macro out of this Ensemble and placing it in the Loop Sampler, it does not function the same. The debugging data on the final output displays "0...and the LS number" and it is static(?!). Inside the macro, the behavior is also different.

Just don't understand how the input data is the same (LS and LE) but inside the Loop Sampler Ensemble, the functionality of the Macro is different...

Ping Pong Loop Sampler.ens

I am determined to figure out coding in Core. I am deeply impressed with the potential of Reaktor, as well as the amazing group of people who share their knowledge both in the User Library and here on the forum! I very much appreciate your help.

Thanks!

--Paul

colB

I would say, don't try to hack an internal component module from one ensemble by one builder into different ensemble by a different builder. They are likely to have different styles and approaches. To make it work you will have to reverse engineer both and understand them properly, and even then, it will probably be more work than a scratch build. Much easier to just reverse engineer one, and update it to do what you want.

In this case, I would reverse engineer and update the loop sampler. Just be aware that it does have at least one bug iirc. There was a thread about that recently where I posted a fix.

It should be easy enough to get some basic ping pong, either by manipulating the polarity of the F input to the various phase macros, or by updating their internal accumulators from just adding to adding or subtracting based on some ping=pong state logic.

The trick will be to do this in a way that the result makes sense from a user POV ;). That is always more work, particularly in a context where there are already lots of modes. So you will have to decide what to do in all those cases, and then implement supporting logic.

Studiowaves

Looks like you're doing pretty good so far. Aside from your immediate concerns, I can offer some general advise you should strive to achieve when core programming in core. Simple stuff really, make sure you understand the difference between low cpu events and high cpu clocked audio events. Avoid using the audio clock to trigger events that don't need to be synchronized with the audio clock and your projects will use less CPU. I love core myself, so much control, but like they say in the manual, you have to come up for air sometimes to reconnect with the outside world. Have fun!!!

P-box

@colB

You have already been very helpful in many of the posts to my questions, Thank you!

After months of banging my head agaisnt the wall with Loop Sampler, I am turning my attention to Ignasi's Live Audio Looper as the basis for a Sample Looper and am making great progress. And yes, you are correct, the coding styles of the two Ensembles are (in my estimation) irreconcilable.

Ignasi's coding is clean and much easier to understand from the perspective on someone new.

The last hurdle, which may just be insurmountable at this point, is to add sample loop fading to Ignasi's looper. But his coding is so clean that the loop transitions placed in the correct spot are pretty seamless.

I hope to post the Sample Looper I am developing out of Ignasi's Live Looper sometime soon in the User Library, and will have the first building block for the Quad Sample Morpher that I first spoke of when I joined the forum.

Thanks again for your help along the way. I suspect I might still have a few thousand questions or so left(!).

@Studiowaves

Thanks for the tips!

Quick links

Unanswered questions