toggle widgets don't always send their state with preset
|Assignee:||Trond Lossius||% Done:|
|Category:||-||Spent time:||3.50 hours|
When mute, freeze, bypass or preview are set to 0 (and appear as such in
.xml file), their value is not sent thru jcom.in when recalling preset.
Moreover, when creating such a widget, they don't work directly: if you use
them nothing gets out of jcom.in. To get them to work, you need to save and
reload the patch.
Date: 2008-11-24 15:32
yes, it is linked to that, see bug #2338920. Repetition filter is not doing
its job properly.
Nevertheless, we need proper init of parameters...
Date: 2008-11-22 15:39
I think this has something to do that we now filter out repetitions by
default. The initial value of toggles are set to 0 as long as you don't set
it otherwise via @default/value. So if you recall a preset the repetition
filter is doing his job according to these @value/default settings.
Date: 2008-11-22 13:45
File Added: jmod.template.control.xml
#2 Updated by Pascal Baltazar almost 11 years ago
- Status changed from New to Resolved
I don't see any unintended behaviour when testing this is modules
repetitions are filtered out by default, but that's a design decision
changing status to resolved until someone argues that there's something wrong (or that it can be closed)
#3 Updated by Trond Lossius almost 11 years ago
- File testModules.zip added
- Priority changed from Normal to Immediate
OK, this is a really serious problem: The module will fail to initialize any parameter with an initial value of 0 or 0.0 if @repetitions/allow set to 0 (this is the default, and is used for bypass, mute, freeze and preview in jcom.ui).
- Download and unzip the attached files
- Start Max and clear the Max window
- First open jmod.notCorrectlyInitiated.maxpat and check the Max window: Only two parameters get initially passed on to the algorithm via jcom.in
- Now open jmod.moreCorrectlyInitiated.maxpat. Now initial values for 10 parameters get passed to the algorithm.
The two modules differs only by all preset values having been changed from 0 to 1.
#5 Updated by Trond Lossius almost 11 years ago
- % Done changed from 0 to 80
The issue is resolved in r5798.¶
I have added x->isInitialised as a flag to the parameter struct. This is initially set to 0, but gets set to 1 whenever jcom.parameter process an change of value. The tests to filter repetitions now also check if the parameter has been initialised. If not, the value is processed even if it is equals the currently internally stored value.
One task is left to do:¶
When jcom.hub receives the /init message, x->isInitialised should be reset to 0 in all parameters.