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.
Statistics: Posted by martignasse — 10 Apr 2008, 10:10
]]>
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...I know, I have to do that. I hope soon. It shouldn't be so complex since the SDK is very simple.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.
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.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?)
So you will always have side chain problems in some particular patches
Let me time to think about a solution.
Statistics: Posted by senso — 10 Apr 2008, 09:13
]]>
If so, would it be easy to implement a forced, total recalculculation every time a preset is recalled?
Statistics: Posted by bsork — 09 Apr 2008, 23:14
]]>
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 !
Statistics: Posted by martignasse — 09 Apr 2008, 22:55
]]>
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.
Statistics: Posted by martignasse — 09 Apr 2008, 22:37
]]>
Statistics: Posted by senso — 09 Apr 2008, 21:36
]]>
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.
Statistics: Posted by martignasse — 09 Apr 2008, 21:23
]]>
Statistics: Posted by senso — 09 Apr 2008, 09:15
]]>
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.
Statistics: Posted by martignasse — 08 Apr 2008, 22:43
]]>