Would this work? (Parameter handling)


#1

Here I’ve made my own setParameter Method.

I have 107 parameters that are automatable, and another bunch that is not. Hence the “if” in the second method.

The gui calls the custom method, so presumably the original should only make it past the “if”, if the caller is the host. Right?

void VexFilter::setParameter (int index, float newValue)
{
	DBG(T("setParameter Called."));

	if ( parameters[index] != newValue )
	{
		DBG(T("setParameter updates gui."));
		parameters[index] = newValue;
		sendChangeMessage(this);
	}
}


//Set parameter without the host knowing
void VexFilter::setParameter (int index, float newValue, bool fromGUI)
{
	parameters[index] = newValue;
	if(index < 107){
		setParameterNotifyingHost(index, newValue);
	}
}

#2

Additional musings:

Original setParameter, as above, except it stores the index of the changed parameter in a list.

void VexFilter::setParameter (int index, float newValue)
{
	if ( parameters[index] != newValue )
	{
		parameters[index] = newValue;
		dirtyList.push_back(index);
		sendChangeMessage(this);
	}
}

The list is in the public scope so then I can just:

void VexEditorComponent::updateParametersFromFilter()
{
    VexFilter* const filter = getFilter();
    
	filter->getCallbackLock().enter();

		std::list<int>::iterator i;
		for(i = filter->dirtyList.begin(); i != filter->dirtyList.end(); i++)
		{
			sliders[*i]->setValue( filter->getParameter(*i), false);
		}
		filter->dirtyList.clear();

	filter->getCallbackLock().exit();
}

In the gui code.


#3

i’m not sure about your second approach.
could work (but i think not in all situations), but i don’t see the point of having a dirty list if i just update the changed parameter only.

the shared dirtyList isn’t a good solution, and the critical section lock is bad design imho. you SHOULDN’T block the audio thread at all for doing gui updates; the way to go is to use non-blocking async message queues.
if your dirtyList increase (especially when automating), you’ll finish blocking the audio thread too frequently.

a better approach (but not the perfect one, there are much more smarter way of doing this) is to trigger an async update for the changed parameter only, not for all parameters, then the gui will take up the async message and update its controls, without the need of blocking the audio thread.


#4

this is built using that approach (despite the high cpu usage which was on debug release and on the usage of recordmydesktop):

parameter automation video

i move the slider, and the host updates the parameter value (you can see it in the automation line) thanx to the use of setParameterNotifyingHost directly from the gui, then the host will call setParameter, thus invoking async updates to every single parameter, so if you have 1 parameter automated, you’ll get a bunch of async messages update 1 slider at a time, but if you got more, your async messages will be compacted and runned simultaneously thanx to the asyncUpdater which “allows an asynchronous callback function to be triggered, for tasks such as coalescing multiple updates into a single callback later on.”…


#5