Transport (play/stop etc). Like, for real

Hooray! it’s my birthday and I’m drunk. So I feel I get a free pass today.

What’s happening with transports? Clearly none of the demo code has any, as I figured out by putting dblue’s Glitch into the Plugin Host… do we just go and rip off Jost’s Transport class? Or do I have to go and look up PPQ and figure out some stuff? Something with counting samples through a AudioProcess? Is there a standard practice? Caveats I should look out for? Surely there is a bit of insight available, I’m prepared to wager a small sum of money that some of you use features like “play” and “stop” in your software. Kids go hell crazy for those things.

Use small words. I’ll be hung over in the morning. I’m going to enjoy the rest of the day and drink a few ciders. Southern Hemisphere R0X0RZ!

(I swear to God it really is my birthday today, but I might try this stunt in 6 months time, so don’t be fooled!)

Happy birthday! Are you talking about some kind of transport UI or the logic behind implementing one?

I was pretty keen on having buttons, and then having the buttons do something, so a bit of both. And it would do all the cool things. You know. And it would probably broadcast things, so that the VSTs are all synched and I send them messages at the right time. I’m thinking DAW long run (because there’s clearly not enough of those on the market), but short term, drum / sample sequencer with VST support. I thought I’d start with the Jost one, hack it down to a bare minimum, and then rebuild it as it begins to make sense. I don’t know if it’s right for my needs, or overkill or… I don’t know what I’m on about.

At the moment, I have four separate synths each counting samples and triggering themselves, running off separate sequences. That should probably be centralised. I just thought that there might be one way of doing things, I’ve used a lot of different pieces of software, and they all seem to have the same idea when you press play. yeah, I’m wondering about the architecture and the implementation logic thing. Does it need to be a singleton, or should I just make one and leave it at that (design patterns are another huge whole in my programming).

That’s a really poorly written post, but you guys get the vibe, right?

(I got drunk and fell asleep in the sun, so I won’t be hung over tomorrow. oh well)

Ok… The goal I’m going to set (for me, not you, although you can play along if you wish) is to get a little app ready to host Jules’ JuceDemoPlugin, and feed it time info so it’s little counters… count.

I’ve taken the Jost Transport class, and hacked off / commented out large chunks, and most of what remains is internal functions/states (play(), bool playing etc). It is still a ChangeBroadcaster, and it now inherits AudioProcessor.

Within my AudioProcessorGraph, I have this connection : MDATestTone->JuceDemoPlugin->Transport->AudioGraphIOProcessor::audioOutputNode
I’m not sure why I think I need to put the Transport in the way of everything else, but I need it to be able to count samples, so this seemed to make some sense.

Jost throws up a ridiculous amount of errors when I try to compile it (on VSE2008), so I can’t step through it, so I thought I might go and have a look at a Steinberg mailing list, they might have some info on what a VST would want?

Any advice would be lovely!

What revision are you using to compile jost?
We are now stuck with juced, due to some real-life problems…
Try older revisions, I’m the one who manages the windows versions of jost.

masshacker, I think (at least according to the readme file) I’m using 0.5.4, and yes, it’s from the Juced site site.

That ellipses after the “real-life problems” looks pretty heavy, don’t feel stuck with Juced! I’m sure there is enough love here to be spread around! Or maybe that’s not the issue…

It might be the case that I have just messed up the compile process, but I might have more luck with some older versions, yes, I hadn’t thought of that.

Thanks for your encouragement!

Ha! Don’t trust the readme file, you have to look at the svn revision number.
Last well working revision is 161.
If you want to know your current juced revision (assuming you’re using svn from the command line) just go into your juced directory then type “svnversion”.

It looks like I haven’t got my PATH setup to do the command line stuff, but Tortoise seems to be telling me I have rev no. 155. I might try the tip and then work backwards. Jules keeps on telling us to try the tip when we whinge about stuff.

I tried out 161, and I’m up to getting it to link… ~1800 errors! I’m sure I just need to fiddle with my project settings. I checked the DLL/non DLL Release/debug options, and it doesn’t seem to be that… I’ll keep digging!

Edit… There was a big message here because I couldn’t get it… I do know now. I’m glad I’m not doing this for a job because all of my colleagues would get sick of me being so god damn emotional all the time.

My Transport class inherits AudioProcessor and AudioPlayhead. the demo plugin so far only changes bpm, as that’s all I implemented… but I’m sure it will do more given time ('tis the plan, at any rate)