On 26.01.24 13:13, Will Godfrey wrote:
I've just started looking at SUBnoteUI, which apart from all the usual
controls and inserts has a double row of harmonic bands.
....
However, there is an occasion where these are changed in bulk.
Hi Will,
probably you are referring to the `mag` and `bw` sliders in SUBnoteharmonic?
Indeed there is a whole array of those, and they are directly accessing the
ars->Phmag[n], which I'd assume to be effectively the parameter object residing
in the core...
Looking at usages of Phmag, I can see *only* read access (which is good)
- from SUBnoteharmonic::make_window()
- from SUBnoteharmonic::refresh()
The latter is called in a loop from SUBnoteUI::refresh()
Thus I agree: these look as a perfect use case for the new GuiDataExchange
system. Instead of grabbing into the core, the SUBnoteUI could have a
local MirrorData block holding the complete array.
Obviously, we'd need to find a good location then to trigger the data update.
I could imagine two quite distinct approaches to that problem.
(1) The first one is quite obvious: whenever the Synth itself detects a change.
In SUBnote::noteout() there is the usual check (SUBnote.cpp, 618)
if (subNoteChange.checkUpdated())
{
realfreq = computeRealFreq();
computeNoteParameters();
/////////// <<-------------- we would add the push-update here
}
(2) an alternative approach would be to look at all write accesses to the
pars->Phmag[i]. Needless to say, this is a bit more tricky, because we'd
ensure we really capture any such access. The relevant ones seem to be
- InterChange::commandSub()
- InterChange::generateSpecialInstrument()
- SUBnoteParameters::defaults()
- SUBnoteParameters::getfromXML()
Has the second approach any benefits over the first one?
It seems to me (is this correct) that there is a call path
MasterAudio() -> InterChange::mediate() -> commandSendReal()-> ..->commandSub()
If the latter is indeed the fact, then we'd call the command change through
InterChange::commandSub() from the Audio thread, at least in some cases.
This would imply IMHO that there would be no benefit from using the second
approach, which has also the additional downside of being brittle. And even more
so, the second approach would trigger on any change message sent down, while the
first approach would only thigger whenever a new buffer cycle starts and the
Synth is slightly delayed anyway by computeNoteParameters()
What do you think? Does this argument make sense?
-- Hermann
PS: another observation: if we decide to go that way, i.e. deliver the
subsynth band parameters by a push update through the new system, then we
would not even have to waste any thought on the issue with GUI refreshes.
Because the GUI would then always just look into its own MirrorData copy.
PS2: I was quite occupied last week with other stuff, but today I made
two further commits. A simple locking with mutex is in place now.
_______________________________________________
Yoshimi-devel mailing list
Yoshimi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/yoshimi-devel
