In a follow up on syncing audio tracks with Dorico as asked by dbudde…
For the stand alone version of Bidule I’ve been unsuccessful in getting a true sync between Dorico and the stand alone Bidule session. Unless you have some sort of plugin that can leech a sync signal and hand it off to the stand-alone Bidule session, It’s not going to happen until Dorico gives us a way to send a clock over MIDI.
If for some reason you wanted to run a Bidule session in stand-alone (say on another machine) in ADDITION to using the VSTi plugin version hosted inside Dorico, then we could probably find a way to get sync signals to the stand alone instance (Via OSC, or through a MIDI, or rtpMIDI connection). It would use the same Sync Extractor we see below, and convert that to a format that can be broadcasted between the various Bidule sessions or instances you want to sync up.
Thanks fort looking at this Brian. It’s pretty much as I expected. So I’m going to stick with editing Dorico library files directly. So far, I’ve been able to get everything I need until some more capable playback features exist.
Why do I want to pay money for something that I already have for free? (Even if the dev kit is free, Bidule isn’t - and any dev kit costs the amount of time it takes to learn it)
It bothers me a bit that apparently Bidule is now 10 years old but still has a “beta” version number - and the reviews I’ve seen all criticise the documentation. That’s a more general criticism of Plogue - for example they added a heap of proprietary commands to the SFZ file format, but there’s no proper documentation for them available. If you don’t happen to own a sample library that uses them, you don’t even know they exist!
Until Dorico playback stabilizes, everything you are cobbling together is a house of cards built on a sand pile.
And after Dorico playback HAS stabilized, you might not need any of it anyway…
IMO “putting together a trill in a 32-step sequencer” isn’t going to sound any better than not playing it at all. YMMV, of course.
But don’t let me stop you having fun, if all this counts as fun for you!
I’ve got it. It’s been registered and in daily use for about 3 years now. It’s gotten numerous updates (fixes and new features added) over that time period. Two of them (One for Bidule and one for some memory management stuff in the ARIA Engine) was actually at my personal request. In the case of the ARIA Engine one, Sebastian sent me a patch to try the very next day (I wouldn’t hold them to that standard on every issue on a regular basis, but I felt really lucky to get that quick of a response with a patch I could try out)!
Since you can now incorporate and bounce plugins and channels from Dorcio, optionally automate it all with your iPad (or any other OSC client), generate trills and ornaments, etc…‘FOR FREE’. Please explain to us HOW. An example project would be nice. Maybe some screen shots.
I’ve put up actual projects, bidules, and screenshots showing examples. Where are yours?
The advantage to working with Bidule (if you want/need this sort of low level interface in the first place) is because you would not have to write an entire engine to get at all the signals/drivers/etc. Just do your simple math/routing and ‘plug it in’. All of the ‘plugin’ structure is already done for you. Are you really advocating that it’s easier to do an entire plugin interface yourself? Is Legree as complete and ready to go out of the box as Bidule (You still don’t have a complete OSC server for instance, and many many other things included in the Bidule interpreter)?
You’ve also got the core engine ready to go for both Windows and Mac. So if you do any custom compiled bidules it should be fairly easy if you follow the SDK guidelines to make it cross-platform ready.
99.9% of the stuff one would want to do with this tool can be done with a basic ‘rat’s nest’ of bidules anyway. The entire point in doing it that way is so you can attach automation to any of the math blocks, and when you’re in the phase of designing things you can attach a little monitor and see exactly how it’s going to behave. You can hook up monitoring and analysis bidules and see what all is going on in REAL TIME. You can link automation to ANY OF THIS STUFF with a few clicks. You don’t have to take things down, recompile, relaunch, audition, wash/repeat/rinse just to fix a routing or math bug, or try something radially different. You’d just ‘re-patch’ to a different chain of logic. Just hook it up and watch/hear the results on the fly!
Short of ‘optimizing’ things that might otherwise use too many system resources, or doing something that requires a lot of deep discrete processing away from the constraints of the sample clock…you’re not going to need to code and compile much.
Tell me…in VSTHost,
Can you insert a monitor at any point in a signal path (Lots of signals and monitor types mind you…individual clocks, gates, sample and MIDI streams, OSC data, and more…viewed via consoles, wave form displays, spectra-graphs, and more) to see what it is doing?
Can you make it round robin a stave from Dorico across different channels/plugins?
Can you make it automatically change articulations based on tempo? I.E. If there is a legato (slurred) passage with a dot over a note, should that be martele or sautellie, or spicatto? At faster tempos you might want martele or sautellie, while at slower tempos you might want spiccato, or even staccato. With Bidule you can build instrument sets like this…even if the individual hosted sample libraries/plugins don’t have these kinds of ‘smart patches’ built in. Since Dorico/Finale/Sibelius/Etc. can send a CC68 legato pedal for slurs, we can let Bidule know to check the bpm signal and choose the right articulation automatically.
Can you have it make an instant drum/percussion map that’ll mix and match pit and kit pieces from several different plugins/sample libraries and play them all from a single stave?
Can you have it set up keyboard and velocity zones to hop channels/plugins at will?
Can you offload resource hogging plugins via dummy bidules hosted in Dorico, that actually remote control an actual live setup on another machine (Again, OSC)?
As a non programmer I searched far an near for a tool that could do these sorts of things easily. I’ve only found one for less than 200 British Sterling pounds…and it’s been so unique and useful that it’s worth every penny. VEP is stronger in some areas, and less flexible in others…it costs a whole bunch more…
I don’t care if it has a version number of 2 million and seven. I bet you have thousands of drivers on your system, and different BIOS stuff in your hardware that is pretty close to the same as it was the day it rolled out.
It’s simple really…if it’s working and doing what you want it to do, then it’s solid software. Why does version number matter?
Honestly…how many ‘proprietary’ things do we not know about Kontakt, HALion, EWPlay, Vienna, Dimension, Presence, Omsiphere, Alchemy, Mach 5, and the list goes on!?! How many of those have ‘any open standard’ support at all?
For that matter, how much inside information do we now (or will we ever) get about Dorico’s inner workings? That’s all property of Steinberg…so today, and in the future, if there’s something I want to do with MIDI and Audio once it hits the plugin or MIDI port stage, I can snoop it, alter it, and do my own thing, so it provides a whole different level of freedom where sound generation is concerned.
You’re ticked off because an engine that 100% supports the open SFZ standard also can do some extra proprietary things? Get the kit if you want to develop a library that uses that stuff. It takes a single email to get information on what the Engine can do, how to do it, and the processes involved in ‘registering libraries/banks’.
If you want to develop in SFZ, I honestly don’t know how ARIA stacks up against something like Dimension, but it is what it is.
Bidule’s documentation is just fine for me. It says what each included Bidule does. What bidules you connect to do what is beyond the scope of any ‘documentation’. It’s easy as pie to connect stuff and both ‘see and hear what it is doing’ using all the monitoring and analysis tools. Meanwhile, they do box in plenty of examples to study, and users often share their personal layouts/groups/presets/etc. Case in point…when you get a new compiler, do you expect it to come with instructions on how to code a video player? When you buy Dorico, do you expect it to come with instructions on how to compose, format, and publish an opera? Of course not! Low level tools for advanced users typically get low level documentation for advanced users. We’re talking about routing signals, occasionally setting up small stacks and buffers, and applying simple math to them, all within the constraints of the sample clock (how much processing can one realistically do and not add tons of latency to a stream?)…how much documentation do you need?
I’ve had no problem getting almost any information I want from Plogue. I don’t even do commercial libraries and they’ve been very good about answering questions (in forum or via email). If I wanted to go beyond SFZ 2.0 and make an official ARIA based library that uses the optional proprietary opcodes, I’m pretty sure they would send me information on the proprietary options if I bothered to ‘ask’.
I’d suspect the proprietary stuff in the ARIA engine mostly has to do with encoding/locking your library and generating a license key. Since I don’t do commercial libraries I’ve never inquired about the possible costs to go with ARIA and ‘distribute’ products for ‘profit’. Check with them to find out…
If you want to create ‘banks’ in ARIA, which can be auto-managed by things like Finale and Sibelius, then you’ll simply need to email them for the information required. Making banks and GUI’s is not all that difficult…I don’t even have ‘documentation’ and have been able to make some of my own. I just cannot ‘register’ the new banks without some help directly from Plogue.
I don’t know what it costs (if anything) to register a bank, but it would make sense if there is some sort of fees and agreements…since the company does have bills to pay and mouths to feed in exchange for their services.
No, it’s not a house of cards on a sand pile. There is nothing fragile about anything I’ve proposed in this thread for as long as Dorico properly supports VST2.x plugins. If/when Dorico totally blacklists all VST2.x stuff, everyone (including Bidule) will need to offer up some new VST3 and beyond plugins. Seeing as Bidule is one of the first and few non Steinberg apps that’ll even load VST3…I don’t anticipate this being much of a problem. In fact, I’ve been able to sidechain VST3 compressor plugins for over a year now in a slew of non Steinberg hosts…well before most mainstream DAWs were even able to natively load VST3 plugins on their own, Bidule provided me a pathway to load and use them.
Uniformity and consistency is really part of the point. Instead of a house of ever-changing cards that are beyond my control…I can manage it in a similar way across all of my hosts. If I build a project today, and open it 2 years from now, it’ll still work the way I made it, unless the host (I.E. Dorico) decides one day to totally revamp the entire playback engine and strip out all of the techniques or something (highly unlikely).
It’s true that they will ADD new features and techniques that I can take advantage of at some point, but the ‘old projects’ should still function just as I made them for many many versions to come (if not indefinitely).
The bidule sessions I build will also be uniform and work in any host/daw at any time.
The point is to be ahead of the curve on playback potential, and have a fully portable integration of all my plugins.
That may be very true, particularly for someone who is going to work only in Dorico %99 of the time. Some of us have clients that want things done from the top down on a different App though. I have some clients that demand Finale, some demand Sibelius, some MuseScore, etc. Of course they can all manage libraries internally to some degree, but with a Tool like Bidule, one can easily keep a far more uniform workflow when it comes to dealing with instruments, techniques, and other playback issues.
And why not? Have you tried it? Math is math, and human variances are human variances. Using Bidule I’ve got the tools to take advantage of the former, and simulate the latter.
First, I would not build a trill in a 32 step sequencer. I’d use a simple arp engine, and add some bidules in the mix to humanize and randomize various qualities according to the tempo/velocity/style/instrument type/etc. Unlike anything ANY of our current scoring and tracking hosts can do on their own, I can also round robin the stuff among different variations and channels/plugins. Since the arp engine in this case is synced up with Dorico, it’ll play at the proper tempo (unlike an umetered ‘sample’ of a trill). I can also add extra variation to the trill directly from Dorico by putting in tempo changes.
The 32 step sequencer would be more for building a custom one shot ornamentation that shows up as shorthand on the score, but plays back really quickly and on the fly. Again it’ll be tempo synced (again, unlike unmetered ‘samples’). Any time I need this I just drop the proper event(s) on the score to trigger it!
Why would my arps and stored sequences/grooves be any different from something Dorico might generate when automatically interpreting and building trills and such for you? After all, I can control it to the most minute details, which might not be the case in ‘the more near future’ when Dorico gets around to implementing automatic translations for this stuff. Hey, someday they might give us tools to build and manipulate all this stuff in fine detail (alot of it IS in the development roadmap), but right now we do not have it, short of writing it all in note by note exactly as we want it to be played (or copying and pasting it from somewhere).
It is fun to me, as is helping other folks learn and find solutions of their own, but the bottom line is that sometimes professionals want to be able to do something NOW. Sometimes it means reaching in the tool box and grabbing a different tool, or WAITING AROUND for someone else to build and implement it.
For me, it’s nice to have a visual based power user Swiss Army Knife like tool at hand to be able to force square pegs into round holes. It’s nice to have all the monitoring and assessment tools to examine things, figure out what’s going on, and put my sinky pinky in the middle of the pie.
Flow charts work wonders when communicating ideas. It’s even nicer when a flow chart is actually ‘functional’…and that is the beauty of a visual based interface. It has plenty of cons to go with the pros…but for sound-design it sure is nice to have the old familiar patch cable approach.
Trying to tear someone apart because he uses a particular tool, and is open to sharing some of the things he finds it useful for is akin to blasting Mozart for writing that passage for the flutes instead of the oboes, or berating a painter for using a bush made of camel hair instead of ox hair.
Going off half cocked with negative opinions when people are simply trying to CONTRIBUTE something potentially useful to a thread (which is totally optional to read or follow) is a flavor of ‘fun’ that blows my mind a bit.
Your ‘fun’ seems to be shooting people down in threads who try to contribute…OK, I can live with that. It’s not personal…I can just point out where my ‘opinion’ is different, and why. You’ve got just as much right to be here trolling challenges as I do to take the bait and try to offer valid and ethical tips and solutions.
My flavor of ‘fun’ is trying to help people meet goals and objectives. While I much appreciate your acknowledging VSTHost in this thread, it doesn’t help a soul unless you’re also prepared to explain to the thread how to make it do a MIDI Channel Bounce for plugin(s) with Dorico. Of course some will be content to wait until Dorico does it on its own…but others like working in Dorico enough to want it NOW…for a given project (or set of projects) that they are doing TODAY. So I offer information on a tool that can do it, along with proof that it works.(as opposed to reverting to some other Score application, or exporting to a DAW for rendering a demo, etc.)
The majority of my posts on these kinds of Forums are sharing examples of methods to make specific things happen for people. For the most part I try to gauge the OP (or the commentary I’m quoting and replying to) so that my information is on topic and ‘valid’. Case in point…I wouldn’t recommend anyone BUY something like Bidule without trying it out first, and I probably would not recommend it to ‘just anyone’ (we can tell alot about a poster by thread history all across the internet, and their equipment/software signatures), and occasionally it’s even people we have met face to face before. Sometimes I miss the mark and make terrible posts, but I do try to offer something constructive, at the level of the OP’s expertise and ability. I’d rather give ‘too much’ information and miss the mark than ‘talk down to folks’.
Not only is it fun for me to be a part of online user communities, it’s also one of my best personal learning methods. I learn from browsing, and when it comes time to post, it never fails that when I take time to do up some example or tutorial to share in these threads, I learn about something new that I had not thought of before. It almost always ends up improving my work-flow, saving me time in the long-run, and allows me to milk more life out of my current technology investments.
Beautiful response, Brian! Communicates my thoughts (and some points that I didn’t consider) so well.
Normally, I would balk at using an application that isn’t well documented, but Bidule’s design is so intuitive and so simple (directed acyclic graphs are supremely comprehensible by most people) that documentation is largely dispensable. To me (a professional software engineer), that’s the sign of very well thought-out architecture.
If I want to code my own Bidules, I can do that; the designer of the software has already sent me the SDK, and the code looks about as easy to reason about as one would expect from such a well designed application. But so far, that hasn’t even been necessary, since I can easily throw together something right there in the software, and end up with a sort of prototype that’s actually 100% useful in performance-critical situations.
Speaking of performance, it’s been rock-solid. As software that’s officially still in beta, it’s more feature complete and more reliable than a lot of products that have seen full-blown releases, including Dorico itself. Some developers are like that; they just will not graduate their product past the “beta” designation until it attains the vision of high polish and bells-and-whistles that they have in their imaginations, regardless of how incredibly useful it is. Besides, since Plogue charges $100 for Bidule, how “beta” can it really be?
With just a couple of days under your belt I’d imagine possibilities are already starting to unfold in your mind.
Once you’ve got a good grasp of simple routing/transformation capabilities, things will start to take off…
Here lately I’m starting to make bidules that will automatically pick string articulations based on tempo. I.E. If I’ve got a note living under a slur that’s also marked with a staccato dot, Bidule can choose between things like martele, sautille, spiccato, staccato, based on attack velocity, dynamic levels, and tempo. That means I don’t have to go in and tag every friggin note in a score to force these things manually! You can grab the bpm from a sync extractor, and have Dorico send a pedal event for pt.legato+pt.staccato. In situations where my auto-translations aren’t quite working out as desired, one would just add a dummy latch-key technique in the expression map to temporarily disable it all.
That’s a brilliant idea. Dorico would be able to handle that to an extent, but not at the level of accounting for tempo.
I’m just establishing and tweaking my set-up as I add more instruments to my score. Trying to see how far I can get satisfying basic notation, then I’ll get into the nitty gritty.
I’ve found a way to get rewire in Dorico. This makes it possible for people to try the free stand-alone demo of Bidule with Dorico. It also makes it possible for registered Bidule users to use the discrete processing build of Bidule and get audio routed back into the current release of Dorico.
This option also eliminates having to mess with virtual midi ports.
Not just for Bidule, but anything capable of running as a rewire slave (Reason, Sibelius, Finale, and more)…
I had used this tool some time ago with Finale in order to use 64bit plugins back when Finale itself was 32bit only. I slap forgot about it until today when I was tinkering with an older stand-by PC that was still run the configuration.