Updating Objects Parameter Displays From Inside Object

#1

Is there an 'official' way to change the value displayed by an object parameter in the Patch UI from inside an object?

I've just discovered (thanks @SirSickSik, via @jaffasplaffa) that it's possible to update the value of an int32.hradio, but doing so seems to cause a (very) short (but noticeable) pause in whatever the Axoloti is doing at the time.

If there's a 'correct' way to do this for the different parameter types, I'd love to know what it is, as it'a really useful for objects that store their own presets internally, or load different parameter settings from SD card (as I've been doing).

a|x

#2

as far as I know, it's just the "pex parameter change thingy" if you want to update the value of a knob parameter. if you're only saving 8 bits, you could also use midi-commands, but I think that might use up more memory to perform. (not sure).

Though, might it be that you're updating the knob "continuously" (as long as you press the "load" button)? If that's the case, you should be able to lessen the load on the cpu by making it update only once. I'm using the updating/loading function quite a lot and rarely notice any problems..

what might help:

if(!(data==prev){
PExParameterChange(&parent->PExch[PARAM_INDEX_attr_legal_name_value],data,0xFFFD);
}
prev=data;

#3

And I just remade the sequencer we talked about and now it freaking WORKS with recalling presets from table.. Works everytime now:

FOR COMMUNITY.axp (11.4 KB)

@SirSickSik suggestion did the trick;
if(!(data==prev)){
PExParameterChange(&parent->PExch[PARAM_INDEX_attr_legal_name_value],data,0xFFFD);
}
prev=data;

And i also think that I rebuild it as simple as possible was good.

Anyway check it out. Thanks for the input. You got me back in the track :wink:

#4

I'm only updating when I need to (i.e. when something changes, as above).

I have a suspicion the problem may be caused by my ancient computer struggling with the Java VM. Might be wrong, though..

a|x

#5

how many parameters are you trying to update at once?
I can imagine that updating of many parameters might take a load on the communication between computer and axoloti, especially with the sequence-buttons..

#6

Just 4 sets of 16 buttons

a|x

#7

might be that changing the state of each of the bits of the bin-parameter cause a bit of overload on the visual processing of your computer, especially if you're using the same computer as input for your sound (don't know if that's the case here..?)

#8

I just tested it with several other objects and it works perfectly in all of them. Recall integer spinboxes and everything :slight_smile:

I am thinking this could be used to make a super clumsy version of the ctrl/i version that reacts to midi cc > save an array with the size of 128 samples and put the numbers 0-127 into the array and the use the parameter exchange to update the spinbox, according to the value in the array...

The array/table can easily be controlled with anything like midi cc input. SO this could work but would be super clumsy.

#10

ok, a bit of background, based on my understanding (of firmware etc )

this was designed for UI changes made by the user, not automated changes... so low volume messages. (modulation sources were designed for automated changes) - so 'abusing' may have unintended consequences :wink:

cpu load...
the call to parameter change in the audio thread, can potentially call a pfunction, so its not just setting a value. I think these are usually fairly 'light' though.

the main issue, there is a separate thread which pushes a usb message for every parameter than has changed (note, it will coalesce on a parameter) - IO is not cheap, so large amount of messages within one 'push' is not good (sent every 2ms) , these messages are not very 'optimal' for a large volumes of data (due to surrounding protocol data) , a large number of changes I think will make the UI sluggish. (probably your issue @toneburst) .... I think its possible lots of messages may cause issues with the watch dog - but id need to confirm this.

as I say this is not bad design/implementation, its just is designed for user interaction, and they only have one mouse :wink:

also... I believe Johannes is working on an improvements to the parameter handling, this I'm not sure if PExParameterChange will still exist in its current form, or considered as part of the 'public api' (though no doubt something similar will be required) - im not saying don't use, just be 'aware'.

#11

They seem like they are working pretty stable. Today I experimented with a delay with 11 parameters, using the PExParameterChange, where I controlled the presets with a ctrl/i to an inlet that controls the presets...... And I tried using a smooth object between the ctrl/i and the preset inlet... It creates loads of sending PExParameterChanges, the knobs and buttons where jumping around like crazy, haha :slight_smile: And got some pretty funy results out of it...... It was a silly attempt to morph between presets, but there is better ways of doing that.

Thanks for mentioning it. Would love to hear what @johannes says about this. There are all ready several objects in the community library that uses this technique and I have also made a few the last few days. Some really good ones like sirsicksik's paraEQ. Would be nice to know if it is worth putting an effort in to it or if the PExParameterChange might be dropped in next update or two.

As long as there is alternative to this I am also okay with progress. I just like the way it works now, cause it is artifcact free. No clicking and no drop outs. This is really important.

#12

Thanks for the detailed explanation.

I suspected as much. Hence my question, really.

The issues I was experiencing wasn't UI sluggishness. The trigger sequencer I was working on actually appeared to pause slightly, when the preset was recalled.

I think the ability to change the values displayed by parameters from within the objects they're attached to is a really cool thing to have, so having less resource-hungry way of making that happen in the future would be cool, I think.

a|x

#13

what do you mean be recall? the normal recalling from memory preset? or from a community object recalling from sdcard?
if its the latter, then its probably due to the way the object is implemented. if its doing I/O, then this should be doing this on a separate thread, which should mean timing is not altered, if however, its doing it from the audio thread (which it shouldn't) then this will cause timing/audio glitches.

also... whilst the preset is being loaded, id expect it to suspend audio processing as well (which would sound like a skip), since otherwise it will potentially be playing the preset with 'random' values (i.e. half with existing param values, half with new... imagine what that might do with a filter, if cutoff and resonance were altered at two distinct times, you could get a nasty resonance spike)

#14

Bad choice of words on my part, there. 'Presets' are read from a table in SRAM which is filled from a file on the SDCard when the patch starts, so that shouldn't be a a bottleneck.

a|x