Avatar

Please consider registering
Guest

sp_LogInOut Log In sp_Registration Register

Register | Lost password?
Advanced Search

— Forum Scope —




— Match —





— Forum Options —





Minimum search word length is 3 characters - maximum search word length is 84 characters

sp_Feed sp_TopicIcon
checkUpdateGUI() workaround needed
No permission to create posts
September 5, 2017
2:14 pm
Avatar
David
Member
Members
Forum Posts: 10
Member Since:
September 5, 2017
sp_UserOfflineSmall Offline

Hi will

I have a slider that needs to change its value when a certain condition in processAudioFrame() is true.

From your tutorial I learned how to control the slider from another control and I hoped this would give me the general direction.

However - it turns out that checkUpdateGUI() can't be emulated. It works only if another control is changed.

 

I added the following code in processAudioFrame():

CLinkedList<GUI_PARAMETER> guiParameters{};
checkUpdateGUI(1, 1, guiParameters ,false);

 

and the code inside checkUpdateGUI :

 GUI_PARAMETER param1 = { 0 };

param1.uControlId = 2;

param1.fActualValue = 0.3f;

guiParameters.append(param1);

return true;

 

now the program runs fine and when checking the locals window in the debugger I can see that the slider's value really changed to 0.3 as I wanted but the GUI hasn't changed. Naturally I also want the slider to move to where it is supposed to be according to it's actual value.

 

So how can I control a slider position directly from my code without the use of another control?

 

Thanks

David

September 7, 2017
2:39 pm
Avatar
W Pirkle
Admin
Forum Posts: 140
Member Since:
January 28, 2017
sp_UserOnlineSmall Online

EDIT:

The work I am doing with GUI updates is for a new RAFX API that won't be out until next year. 

If you are going to try to do stuff like this (there are reasons why sending GUI updates from the real-time audio processing thread are a bad idea) then there are a couple of workarounds, one of which is to use the Advanced GUI API to take control of your GUI elements on your own.

For now, that is really the only easy option, however there are engineers who would tell you not to do this - the only thing that you should alter after the processing loop are meter variables or other read-only GUI controls. For example, what happens if someone is moving your slider at the same time you try to change it programmatically? Having your audio and GUI processing threads out of sync is a bad thing.

The best thing is to try to come up with a different design pattern, or if that isn't possible, use the Advanced GUI API - there are tutorials that show how to control GUI elements from within your plugin.

http://www.willpirkle.com/supp.....tutorials/

- Will

September 8, 2017
8:24 am
Avatar
David
Member
Members
Forum Posts: 10
Member Since:
September 5, 2017
sp_UserOfflineSmall Offline

Agreed. Having the GUI and audio threads out of sync is not something you want. My plan was to leave that slider alone and let the program control it, but of course other users may want to touch it and see what happens.

So may I suggest a future development:

Add a boolean field for the control object. Something like meterControl = true or  maybe passiveControl = true.

That way, when a control is "meter" or "passive" it will not accept GUI changes from the user, but only react visually when the program is changing the control's internal value.

 

We can ask why go with all that trouble of turning a slider into a meter instead of just using, uhm… a built in meter?  

Creating a control object that you can't manually control seems redundant at first, but after more thinking we can justify the purpose.

 

Let's think of a dry/wet knob of say, a customized reverb effect, where the dry/wet amount is determined by the volume of an incoming signal. When the signal is loud the reverb is 100% dry (no effect) and as the signal fades out the reverbs amount increases (100% wet when volume is at zero).

The knob itself is now just a visual indicator. It lets us monitor the ratio of dry/wet which is calculated from the incoming signal. The incoming signal is not affected if the knob is moved by the user because the knob is currently disabled for manual use.

As the signal flows through the system I would prefer to see a knob labeled "dry-wet" moving from left to right instead of meter element moving up and down simply because in my mind meters are associated with volume and not FX amount.

It becomes even more obvious if you think about several elements all moving at once. You want a user to easily grasp the GUI automation as if he was tweaking the knobs himself.

And that in short is why I think GUI elements should also have a "meter" mode and that control between the program and the GUI should be a two way street.

 

I hope that you will get to it sometime soon… until then my project is kinda stuck J

 

David

September 8, 2017
9:01 am
Avatar
W Pirkle
Admin
Forum Posts: 140
Member Since:
January 28, 2017
sp_UserOnlineSmall Online

The new RAFX2 API won't be out till mid 2018, so don't wait on that. It changes the GUI paradigm significantly which allows me more flexibility while still being thread-safe. 

Use the Advanced GUI API - your project won't be stuck any more. You can take full control of all your GUI elements and do what you want with them. I created the Advanced GUI API to specifically address stuff like what you are wanting to do, and make the GUI development as open-ended as possible - of course there's a bit of a learning curve to go through, but plenty of people are using it now, and I also use it all the time for customized output graphs and the like.

Feel free to create your own meter object, subclassed from CVuMeter, but looking like a knob if you like. You can then assign it as a meter and it will work as a read-only object.

Also, try to list the number of plugins out there whose knobs/sliders move in response to the audio streaming through them (not automation). Think of whether this would be confusing to an average user who has never used your product before. 

- Will

September 8, 2017
1:57 pm
Avatar
David
Member
Members
Forum Posts: 10
Member Since:
September 5, 2017
sp_UserOfflineSmall Offline

Creating a custom meter that looks like a knob will actually solve my problem. Never thought about going that way.

I no longer have to wait for the new API but I will definitely want to see the new upgrades once they are here. I still think the programmer should have the freedom to connect the bytes both in and out of the GUI. One idea that I had was something like "tutorial mode" that demonstrate what a knob does and then the user is asked to repeat the move. But that's off topic for now and I have some tutorials to read...

 

Thanks

September 8, 2017
3:38 pm
Avatar
W Pirkle
Admin
Forum Posts: 140
Member Since:
January 28, 2017
sp_UserOnlineSmall Online

Creating a custom meter that looks like a knob will actually solve my problem. Never thought about going that way.

If you do a port out to AU, VST or AAX, you can see how I do that with the Analog VU meter -- see the CVuMeterWP object in the ported project. The analog VU meters are done with an identical kind of graphic for CAnimKnob - a "strip animation" of the VU needle in different positions. The drawing code for the object was hijacked and slightly modified from the CAnimKnob code. You could replace it with your knob graphic, taking care to make sure that all the sizes, number of images, etc... are correct. So that is almost already done for you (!) but you'll need to do a Make XXX operation to see the code. See the last else() statement in CVuMeterWP::draw( ) for that - and the CVuMeterWP comes with a connected envelope detector to give realistic ballistics to the motion of the needle (or LEDs) and you could just remove all that stuff since you wouldn't need it.

should have the freedom to connect the bytes both in and out of the GUI

This is kind of a hot topic - there are arguments about just how well connected the GUI and plugin should really be; e.g. the dual-object VST3 spec does everything it can to prevent you from letting the GUI and processing objects communicate directly.

That said, I designed the new RAFX2 API to give you full freedom with sending and receiving data from the GUI and across APIs with a change in how the GUI is compiled into your project. And there was a lot of work in guaranteeing thread-safety between GUI and processing threads that I had to implement to make it legal.

One idea that I had was something like "tutorial mode" that demonstrate what a knob does and then the user is asked to repeat the move.

See the MIDILearn project after you get there with the GUI API tutorials - that was a request from a user that involves a complex series of operations between the user, GUI and MIDI controller. 

- Will

September 10, 2017
12:14 pm
Avatar
David
Member
Members
Forum Posts: 10
Member Since:
September 5, 2017
sp_UserOfflineSmall Offline

This is pretty advanced stuff. I will have to get back to it in the future after I will learn more.

 

For now I came up with another approach after digging into advanced GUI tutorials 2 and 3.

 

To make things easier I am working on a simple project. I have 1 textbox in the advanced GUI that will update a counter every time the processAudioFrame() completes a cycle. If this will succeed I will change the textbox to a read-only slider and the counter to something more meaningful.

 

The aim is to take advantage of the GUI_TIMER_PING function to recreate a CTextLabel as I want by calling showGUI from inside GUI_TIMER_PING and passing a VST_GUI_INFO object to redraw the textbox with new text.

 

At the moment it is only partly working because while I was able to access the textbox and change the value, after 2 or 3 calls to showGUI the pointers and bitmaps get lost somewhere in the matrix so the counter is still not running. In the past few days my debugger is working overtime.

Forum Timezone: America/New_York

Most Users Ever Online: 36

Currently Online: W Pirkle
3 Guest(s)

Currently Browsing this Page:
1 Guest(s)

Top Posters:

Skyler: 47

Derek: 41

Peter: 41

clau_ste: 39

Frodson: 38

Gwen: 32

EZB: 24

lppier: 23

Msaldaña: 18

Jorge: 17

Member Stats:

Guest Posters: 1

Members: 478

Moderators: 1

Admins: 4

Forum Stats:

Groups: 11

Forums: 29

Topics: 479

Posts: 1870

Newest Members:

certvalue111, sobhana s, sam, annaharris, Marie Weaver, kev, Steven, Mr Anderson, mguy, omelc

Moderators: W Pirkle: 140

Administrators: Tom: 65, JD Young: 80, Will Pirkle: 0, W Pirkle: 140