preset values storing

[martignasse]

hi all,

in a patch, the "preset manager" store the values of math modules (the = module, for what i tested), even if they are connected to a "data in" module.

can someone confirm that.

is it normal ? it seem's not for me.

[senso]

Yes the preset module stores most of values in the patch.
Since the math modules are recalculated in real time, is it a real problem?

[martignasse]

the problem is that :



in a patch, the B connexion of the "=" selected math module is linked to the "Track choice" Data In module, and it's value is 3.

now, if i choice a preset, the value off the B connexion will change according to the value stored in the preset, say 0, despite the value of the Data In module (who is always 3). And it will stay like that.

I can understance that the preset store the values of math modules, but why it isn't reevalued in real time if a connector is linked.

the result is inconcistency in the data flow, and it's not good.

a solution could be to make a sub-patch to isolate the math logic from the preset modules, i'll try that.

[senso]

I understand your pb, and the sub patch is a goo idea.
The perfect solution should be to add an option in all modules like 'not stored in preset' but I need time (long) for that...

[martignasse]

ok,

after quick test (but long implementation;-)

it seem's to work with the sub patch solution, i have more deep test to do, but it look good.

and yes, an option to "not store" the math module in the preset is a good idea, but if we have a temporary solution (i'll confirm after deep test), it's not so high priority.

PS : if only usine had an SDK in C/C++,surely i could help you about your "time" probleme. But i'm sure you do the good things to stabilize the usine core, making a future SDK rock solid.

[martignasse]

and to let you know about what i was working on to fall in front of this problem, as i'm sure it can be interesting for lot of people.



some patch to control with only two button and tree knobs (on the left), some preseted EQ in an arbitrary number of track.

PS : for sure it's to be controled from my BCR, but i have problemes with other part of my workspace causing some "SwitchBufferTimer" error (or something like that) breaking the midi communication between the BCR and usine, grrrr.....
I have to make another thread for this one !

[bsork]

Is this a side effect of the relatively new behaviour where recalculations aren't made unless the input values have changed to save on CPU? (I do remember right about this tweak, don't I?)

If so, would it be easy to implement a forced, total recalculculation every time a preset is recalled?

[senso]

but i have problemes with other part of my workspace causing some "SwitchBufferTimer"

please send me your workspace by mail, I'm not a big fan of this kind of messages...

PS : if only usine had an SDK in C/C++,surely i could help you about your "time" probleme. But i'm sure you do the good things to stabilize the usine core, making a future SDK rock solid.

I know, I have to do that. I hope soon. It shouldn't be so complex since the SDK is very simple.

Is this a side effect of the relatively new behaviour where recalculations aren't made unless the input values have changed to save on CPU? (I do remember right about this tweak, don't I?)

For the preset recall, things can be more complex than appears: as it can take a long time to recall the preset (especially with a huge VST) this operation can't be handled in real time: we can't afford to cut the sound when a preset is recalled. So this operation is done in a second 'thread' not in real time priority.
So you will always have side chain problems in some particular patches
Let me time to think about a solution.

[martignasse]

please send me your workspace by mail, I'm not a big fan of this kind of messages...

yep, i'm not a fan too.

i'll try to send you the "thing" tonight.