DSP Robotics Support

I think I've found a bug. When you have two code components in series and the last one has the code executed in stage(0) it ignores values that are generated by previous code components in stage(2) - they also have to be generated in stage(0). It seems like if the stage(0) what executed in all components first and other stages get computed after stage(0) is finished in all code components. This gets very obvious when using poly.

I consider it a bug because if effectively makes stage(0) very inconsistent. Way around is to avoid using it and use conditional jump in assembly code instead.

That's the normal behavior. That's the reason why the stages exist.

MyCo wrote:That's the normal behavior. That's the reason why the stages exist.

I mean they are executed in this order:

stage(0) in first code module
stage(0) in second code module
stage(2) in first code module
stage(2) in second code module

The problem I have encountered was, when using mono to poly module. A parameter in poly section gets calculated using a value that comes from a mono section. mono to poly obviously gets executed in stage(2) cos' it fails to send value to stage(0) in poly section.
To be more specific I have tried to make a random multisamper that picks a sample depending on a randomizer (noise generator in range 0-1) from mono section. However the sample picking algorithm gets executed in stage0 and the schematic fails to load the value from the randomizer.

I have made a custom mono to poly via trogs array to mem. To create one sample memory slot that one assembly component writes to in mono and second reads in poly, but it was not stable. It crashed FS on startup if audio device was on on startup.

stage(0) is always executed only once.
In case of a mono stream if it's activated (e.g. taken into the signal chain by a selector)
In case of a poly stream whenever a new voice is initiated.
stage(2) is always executed after stage(0).
If you want to use any data in stage(0) in the poly section you have to create it in stage(0) in a poly section because the mono section already executed stage(0) and won't do it again until you switch it with a selector.

But why don't you just do everything in stage(2)?

stw wrote:But why don't you just do everything in stage(2)?

because the operation has to be calculated only once at the start. I was just surprised that the component staging is executed all at once per stage and not stage by stage per component. Looks like I'll be better to execute inter-component calculations in stage2 and jump them after first sample instead of stage0.

KG_is_back wrote:

stw wrote:But why don't you just do everything in stage(2)?

because the operation has to be calculated only once at the start.

Then do your stage(0) calcs/assignments in a poly stage(0) and not in a mono stage(0) if you want to use it in a poly section. This should avoid the hassles you encounter in the description.

stw wrote:

KG_is_back wrote:

stw wrote:But why don't you just do everything in stage(2)?

because the operation has to be calculated only once at the start.

Then do your stage(0) calcs/assignments in a poly stage(0) and not in a mono stage(0) if you want to use it in a poly section. This should avoid the hassles you encounter in the description.

no stage0 bug.fsm

Cool I've totally forgot about that one But I've got better:


The base of my problem is - it's too random ...I'd rather use oscillator to create the random noise pattern, so on plugin reset the pattern resets too. Giving me the same audio when I render the track more times.

Yyyym, so you need random random or quasi random?

Actually it doesn't have to be random at all ...I've already sorted it out. mono stream to "mono to float" primitive triggered by "midi mono" primitive. Plus some afterload and empty selector cos it was bugging a little