Bug #49

toggle widgets don't always send their state with preset

Added by Trond Lossius over 11 years ago. Updated over 11 years ago.

Status:ClosedStart date:2009-05-24
Priority:ImmediateDue date:
Assignee:Trond Lossius% Done:


Category:-Spent time:3.50 hours
Target version:0.5
Branch: OS:


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
Sender: ndeflache

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
Sender: mr_nilson

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
Sender: ndeflache

File Added: jmod.template.control.xml

jmod.template.control.maxpat (17.9 KB) Trond Lossius, 2009-05-24 01:58 pm

jmod.template.control.xml Magnifier (653 Bytes) Trond Lossius, 2009-05-24 01:58 pm

testModules.zip - Two test modules illustrating the problem (4.02 KB) Trond Lossius, 2009-07-31 08:28 am


#1 Updated by Trond Lossius over 11 years ago

  • Assignee set to Trond Lossius
  • Target version set to 0.5

#2 Updated by Pascal Baltazar over 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 over 11 years ago

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

To test:

  1. Download and unzip the attached files
  2. Start Max and clear the Max window
  3. First open jmod.notCorrectlyInitiated.maxpat and check the Max window: Only two parameters get initially passed on to the algorithm via jcom.in
  4. 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.

#4 Updated by Trond Lossius over 11 years ago

I have added a test in r5795 illustrating the problem. I think it is pretty easy to solve.

#5 Updated by Trond Lossius over 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.

#6 Updated by Trond Lossius over 11 years ago

  • Status changed from Resolved to Closed

Resolved in r5800. All parameters will be output when the module receives the /init message, regardless of @repetitions/allow.

#7 Updated by Trond Lossius over 11 years ago

  • % Done changed from 80 to 100

Also available in: Atom PDF