AudioMatt

fffb~ seems to be clearing itself when another poly is dynamically loading.

I know I've posted a lot today. I *wuv* you bicycle nomakers. sorry to make so much work.

fffb~ seems to be clearing itself when another poly is dynamically loading. 

I know I've posted a lot today.  I *wuv* you bicycle nomakers.  sorry to make so much work.

feature-report-fffb-buffer-erased-in-dynamic-poly

... biquad~, reson~, comb~ and delay~ :-/

... 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...

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.

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.

Alex,
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?

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...

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.

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.

[feature report] fffb~ buffer erased in dynamic poly~