Storing objects in processor and splitting Audio and Gui

Audio Plugins
1

Hello, I have a question about storing objects in the processor and splitting between Audio and Gui-Stuff in my classes:

I want to make a VST-Plugin wich contains a Playlist where you can drag and play AudioClips, like the Playlist in Pro-Tools.
I have a Playlist-Object, wich holds an OwnedArray for the Channelstrip-Objects and in each Channelstrip-Object theres an Pointer to the corresponding AudioClip-Object.
All of the classes inherit from the Component-class an do both audio-relevant and gui-relevant stuff like starting an AudioTransportSource or drawing Thumbnails. To make sure that the state off the objects doesnt get lost when the plugin is closed and opened again int the DAW, i have simply put the Playlist-object in the processor, so the editor fetchs it everytime he gets created.

Is this bad practice? Would it be better to make objects that are either audio or gui relevant and store only the audio-objects in the processor?
Sorry for this newbie questions but I am new to audioprogramming and dont know how to do it the best way.

2

It’s best to aim for completely independent audio and GUI objects. You shouldn’t be inheriting Component for stuff that could also be used in non-GUI contexts. The GUI objects should preferably be just “views” into data that is actually handled elsewhere.

3

Thanks for the quick answer. I will restrucure my project to seperate between those.
So I guess its also bad practice to store Gui-Objects in the processor, to keep their state(Even if they are only Gui-Relevant)?

4

I wouldn’t be happy to have any kind of a Component derived object as a member of the AudioProcessor. If you need to store state of the GUI objects in the AudioProcessor, I would suggest to do that in some other way. (For example by making the GUI serialize its state into a ValueTree and then setting that ValueTree in the AudioProcessor.)

I would make all the AudioClip, PlayList, ChannelStrip etc objects not rely on the GUI at all. There would be separate Component subclasses that could then allow viewing/editing those. Those data-only classes would be members of the AudioProcessor.

Besides the code design issue, there are performance/memory use concerns. Say, you have 10000 of the AudioClip objects, not visible in your GUI at the same time. You would still be paying the cost of 10000 Components alive in your plugin because the components are holding the data of the AudioClips…

1 Like
5

Thanks for your detailed answer, now its more clear to me!
One thing: when you wrote “Those data-only classes would be members of the AudioProcessor”,
you dont mean the separate Component subclasses that allow viewing/editing?

6

No, of course not, that would again negate the whole separation of concerns design. The object editor components would be children of the main GUI editor.