[feature report] fffb~ buffer erased in dynamic poly~
… biquad~, reson~, comb~ and delay~ :-/
The first time I bang the inner-ffb it just clicks – the second time it starts working – I think your inner-ffb patch has a bug…
Ok, I’ll check it out as soon as I’m near a max machine but the bug still stands. Buffers get erased as soon as another voice switches. It may be that my artfificial delay isn’t long enough got your machine.
I took a look at it. Appears to be the vector sizes that affect it. I’m running at 2048/2048. Either way… bleh.
hrm… I take it I’ll have to find a workaround? or am I being antsy?
I’ve looked again and confirmed your report, using slightly different patches. It would appear that if you load a patcher within a poly within a poly that will also restart dsp for the outer poly~ – which means that this trick is no good for dynamic patch loading (I had previous thought of doing something similar to have different patchers across cores).
ffb~ obviously clears it’s internal memory when dsp is restarted.
How vital is this dynamic loading to your overall task, and what platform are you on? I have an alternative that may be of interest, but it’s Max OS only…
I’m on a mac. What did you have in mind?
The patch I’m working on has 27 voices, each voice generates a melody and plays it. The parent patch "arranges" the instrumentation, deciding how many of which subpatch there is.
It’s definitely necessary to use poly~ but It’s possible that I could instantiate six [poly~ 27] objects and just use mute.
Well – actually poly~ isn’t 100% necessary….I have a pre-release object that can be used for dynamic patch loading. It is similar to poly~but lacks several features (upsampling / midinote and note message handling) whilst taking a different approach to voice allocation (which is done using a targetfree message) and multithreading.
Unlike poly~ the dsp chain of each loaded patch is not affected by changing the number of voices, or loading a new patch (which is done in slots rather than than for all loaded patches).
There are a few other differences which are designed to make possible the things I wanted to do with the object, some of which cannot be done with poly~.
Although the object is "pre-release" it is over 3 years old, and has been thoroughly stress tested and gigged with.
If you are interested in checking it out feel free to drop me an email at ajharker [at] gmail [dot] com.
If you can workaround with a poly~ solution that works for you then you may prefer that, but it is my intention to release my object eventually, so I’d be happy for you to look at it.