Audio plugin host with multi file audio player and recorder

Hi all,

I just published a version of the audio plugin host extended with a multi file audio player and a recorder
here on github (based on current JUCE 4.3.1)
It should be running stable (tested under Windows 10 and a bit on Mac) and the code is hopefully tidy and fairly documented.
One UI controls both player and recorder and you can add multiple files via multi bus configure audio I/O.
Waveforms are shown with zoom function and input monitor is shown when pressing the record button.

This is how it looks like in a simple Karaoke setup:

Have fun!
@jules, @fabian: feel free to merge this to the official JUCE examples if you like!

[details=fixed limitation][fixed as of Jan 30th: Known limitation: do not add multiple player/recorder nodes; this leads to undefined behavior/crash.
This might be something that should be solved generically, as we also might not want multiple audio/midi I/O nodes because they are always accessing the same I/Os (as of today at least).][/details]

Harry G.

3 Likes

I don’t understand why it would have global variables or such that would that make it work like that…?

1 Like

Awesome, I’ll definitely have to check this out! I’ve managed to do a bit simpler version that has so far fulfilled my needs. I do have a list of improvements so it will be interesting to see what are the differences and similarities between our approaches, and what I could be able to borrow from your code base, or visa versa if I find things that I’ve done better (not likely) :slight_smile:

As my nodes are a lot more experimental I don’t feel comfortable (and after your release, not even the need) to share the code just yet, but I’ll come back if I make any progress on either of the code bases. Being able to have multiple nodes has been one such feature. I have a feeling that we both took similar shortcuts for just getting things done :smile:

Hi Xenakios,

this is because I designed it that the player UI also controls the recorder.
With some effort, I could make it working with one player and multiple recorders.
But multiple players don’t fit in my concept - which player UI should control which recorder?

As said, I think this should be solved in a generic way, as is also makes no sense adding multiple other I/Os that cannot be configured separately.
Also don’t forget that the Plug-in Host still is just a Demo…

Harry G.

OK, I fixed the above mentioned limitation.
Now only one internal filter of each type can be added.

I think this is a generic solution that makes sense for today’s Plug-in Host already.
Therefore I also posted it as a PR.

@zax: yes, would be interesting to share, come back on any progress - we can only learn from each other, even from experimental code!

Ok, had a look, and some quick thoughts what I got when I skimmed through your code:

I skimmed through the code and it is very obvious that your solution is way more advanced when it comes to features. There are also a lot of stuff that I haven’t had to worry so far, for example that multibus configuration that I’ll be heading myself, so it will definitely become very handy for me.

On the other hand, we have completely separate philosophies here in play, as I opted to strictly have one player node per file, as well as one recorder node per recording. My only problem in being able to create multiple of any of these is the way I’ve slipstreamed them into the filtergraph, so they don’t currently actually fulfill the AudioPluginInstance completely. So there are a couple of hacks there :slight_smile:

I do have a clear separation between these two nodes, all down to the recording plugin editor view. And this is really something that fits my philosophy better than your solution, but I must admit that it’s a matter of taste. Except for the fact that you have to create a lot more elaborate architecture for being able to connect all these together in a nice way, where instead it’s a lot more simpler an straight forward for me.

And as you did not have any offline rendering functionality implemented, I can’t tell wether your solution could handle that or not, did not dig in deep enough for now, but I’m either going to dig in or hear from you. In my solution the recording get’s it’s own thread that are separated depending wether you’re rendering offline or running live.

Couple of nice things I found already is that you have a dummybuffer in use, and that might be a solution for one of my problems to be able to control when the graph is running through and when it is not. And those wave form displays, although simple, we’re next on my list for doing on those players, so although I guess you already pretty much gave your permit, I thought I still asked wether it was ok for you if I just directly incorporated those into my own solution?

Otherwise I’ll have to focus on other things for now for the next week, and fix my own issues of why multiple plugins can not currently be generated. It wasn’t because of any kind of similarities between our solutions after all, but the result is the same for us both :slight_smile:

I’ll report back on a few weeks when I have the time to come back to this, and have more spare time to spent on looking your code base more throughly, and when I have the time to continue working on my own file read / write nodes / plugins (after I make them to actually fulfill the contract properly)

Nonetheless, this will surely give me a lot of nice insight on several things, and I’m hoping that I’ll have something to share back after few weeks. It’d seem to be that there just might be couple of sections where we should plainly just merge our code together, but because of the differing philosophies, we should not use the same editor view code IMO, except for those few features (mainly audio display).

On one final note, I got your engine to crash when I press the mute button on the player/recorder ui if no files are loaded. I’d gladly give more information, but your debug build contains like a thousand of assertions that just completely block the usability of trying to get to the point where toe crash actually happens. But I’m sure its easy for you to spot even without any extra information on the matter.

Very nice work still!

Ps. I’ll be actively monitoring this thread, so if you have any questions or would like to hook up for a chat around this matter, send me a PM. If you make any new progress, I’ll find them from this thread. I’ll paste my code here when I’ll eventually get things properly done :slight_smile:

Pps. Just to add a screencap of my version here:

Hi @zax,

thanks for your comments and for finding the mute button bug - there’s always something that you miss during testing…
Fixed now and added reasonable UI behavior!

I do have a clear separation between these two nodes, all down to the recording plugin editor view.

What I wanted is to run everything in sync, like a small DAW (where I must admit that it can differ by up to one block size I think).
This is why I connected the nodes: the player UI also starts the recorder synchronously.

How do you control when your FileOut node starts to record?
Does it record as soon as you chose a file name?

And as you did not have any offline rendering functionality implemented, I can’t tell wether your solution could handle that or not

In fact this is my next task to work on…
But my implementation consists of 2 clean separate plug-in instances, so it should work I hope…

And those wave form displays, although simple,

I started from the Juce examples, but added some intuitive UI behavior and fixed some issues.

I thought I still asked wether it was ok for you if I just directly incorporated those into my own solution?

Why not - it’s public on GitHub anyway…
(thanks, that reminded me to add some license, at least for non-liability)

I’ll paste my code here when I’ll eventually get things properly done :slight_smile:

Yes, would be interesting to compare!

Cheers,

Harry G.

Hi all,

I updated my variant of the audio plugin host with multi file audio player and recorder to JUCE 5.1.2 or to be exact to todays master (2a15a9bea).

Additionally stability was improved.

Location is still the same on github
Have fun!

2 Likes

Is this still usable or am I too late to the party? (JUCE 5.4.3)

If too late, anybody know of anything similar that’s current?

Thanks

In General yes. I am still working with it.
If it doesn’t work with recent Juce versions, I’ll update it pretty soon.

PluginSharedData.h needs some forward declarations

class AudioSlaveRecorderPlugin;
class AudioPlayerPlugin;

class AudioPlayerPluginSharedData {
:

Hi Folks, looking for a good audio player in the context of a plugin and I found harry’s great work here. I am getting compile errors on JUCE 5.4.5 - is there a better alternative now or should w try to fix them. Harry?

Ciao Harry
have you a working code (for JUCE 5.4.7) for this AUDIO-PLUGIN-HOST with player and recorder…

Thank you
R