Here’s a great place to browse for Bidules people share, search/participation in existing threads on things folks have already been asking, and opening up your own new threads:
https://www.plogue.com/phpBB3/
For specific Dorico > Bidule questions I see no reason not to start threads here. If it’s more about getting things working in Bidule and building stuff for that you’ll most likely get more/better support over at the Plogue forum.
Oh, for sure. I just didn’t want to start posting a slew of Bidule questions in this particular thread.
I’m happy to kick off an entirely new thread dedicated to using Bidule with Dorico, or to contribute to an existing thread on that topic.
dbudde,
To catch you up to speed on the topic, since MiloDC already got the VST variant all I’ve done is send a few screen shots showing some example screen shots of some ways to route things via PM.
If you’re wanting to try to find a way to patch the free demo into your system and get it working with Dorico in a round-about way fire me an IM. I’ll have to try some things here myself first (and it could be a bit different from system to system). I’m reluctant to try to toss up instructions here because what will work for system A might not work for system B when it comes to attempting to use multiple clients over the same audio device, etc. It’s also worth adding that I know very little about Macs, but with a PC I have some experience finding ways to use things like loopMIDI, Jack2, ASIO4ALL, reaStream, etc. to patch MIDI and audio streams around from app to app.
Of course the VST version is easy as pie…you’d just add it to the whitelist and go to town. Getting it to work stand-alone with Dorico would be more of a, “Try this with your rig and see if it works.” back forth kind of thing…
I’m finding it hard to see exactly what bidule does that something like the free VSTHost can’t do. (The only “obvious” thing I saw were networks packaged to look like a single component, but you can run multiple instances of VSThost to do the pretty much the same thing)
Of course bidule looks prettier, and it might be a bit easier to use - but I’m more interested in the functionality than the cosmetic features.
I’ve been using VSThost for a few years. There was a bit of messing about at the start to get it working well - it works better when limited to a few cores on a big PC rather than letting it spread everywhere. But once it was set up correctly, it “just keeps working”.
Not even close Rob…Bidule is more than a simple chainer host to load multiple plugins.
Bidule isn’t very pretty really. It’s just very functional. It lets you get fine control over very low level MIDI and Audio events. When one first starts fiddling with it, it comes across as little more than a glorified patch-bay, but it can be so much more. Imagine if you could take every plugin you own, and mash them all together into one massive super-plugin, and also get a pretty big stack of typical DAW level functions on the side! This is Bidule…
The list goes on and on really. In a sense it is a full featured DAW with a low level Visual/Object oriented interface so you can chain the elements together and build your own stuff.
You can combine all your synths, samplers, and effect plugins to create a super plugin, or transform a PC into stand alone super synth/sampler. It also has plenty of tools to build your own instruments from raw oscillators/samples/filters/etc…so it’s a bit of a sampler and synth engine in and of itself. In theory, you could even build bidules (albeit very complex ones) to do internal granular and wave-table synthesis (easier to just buy a plugin that does these things, but the point is you CAN build it directly in Bidule thanks to its low level tools, configurable buffers, and special math and variable objects).
Just a few examples of things I’ve used it for with Dorico Already.
There’s a lot more really when it comes to tweaking and refining the sounds of all of the above…so it’s just a few of the bigger examples. They don’t just apply to Dorico though…It saves me all kinds of grief trying to port ideas around between apps (Dorico, Sibelius, Finale, MuseScore, CuBase, etc.)
So essentially, I can already do so many things in Dorico TODAY, that could be many months down the road as a native Dorico playback feature. The same goes for other Scoring Packages and tracking DAWs. There are also alot of things that all of my DAWs can do, but through such different processes and work-flows that it gets really complicated fast. Bidule helps me slim things down so it all works more or less ‘the same’ across all of the different hosts.
OK, I get the message that you don’t know much about what VSThost can actually do, to make an objective comparison.
Rob,
I do believe I have listed a number of things that the free VSTHost does NOT do, and I have not thought of nearly everything. It’s stuff off the top of my head. I’ve put quite a few hours into testing and using both apps so please do not patronize me. I will bury you…It is you who does not quite understand the scope for which Bidule was developed to cover as a ‘sound design’ and ‘live performing host’ platform.
I would not recommend just anyone go out and willy nilly plop down $100 for an app they could rival for free. I sensed someone here who has invested heavily into high end sample libraries. He wants to use them now, in all of his hosts to full potential and beyond, and he most likely wants it to be implemented in a logical and flexible work-flow that is easy to find and tweak things at the drop of a hat. I think he’ll most likely get his money’s worth or I would have kept my trap shut about recommending any non Steinberg ‘pay to use’ options in this forum. If Steinberg had something similar right now, I would have linked to that first, etc.
VSTHost
I could go on and on here, and that’s just with stuff VSTHost doesn’t do at all (or only at very rudimentary levels). When it comes to setting up a logical and pragmatic workflow with all of the the tools available the list gets even longer.
Brian, thanks for the extensive list of capabilities that exist in Bidule. To be honest I have never taken this product seriously because it still isn’t released as a 1.0 or greater product. I tend to view this means it is either very buggy, or is still in Beta.
So, if you can I’d like to see examples of the following that you mentioned in your list:
How to sync up an audio file with Dorico
1a. Can it do Video files?
1b. Can you make tempo maps from said audio file and have Dorico tracks follow them?
How to create automation data on continuous controllers,
Thanks, and no hurry. Just if you have the time and inclination to share.
The thing with Bidule is that it’s mostly low level signal routing and a ton of math modules (which you can make yourself when you can’t find one provided that does the job), so there’s not much to be ‘buggy’. Since Plogue as been doing DAW engines for quite some time now (Sibelius and Finale included), they’ve got a solid base of code all compiled and ready to go, and they know the stuff like the backs of their hands.
If you build a buggy bidule, it’s your bidule most of the time. True bugs do pop up sometimes, and Plogue usually fixes them pretty dawg gone quick if people report them. Case in point…I once reported that HALion window sizing was off when using the VST3 version…they got with Steinberg and had it fixed in a few short weeks. When it’s your bidule that’s off…they are also really good about helping sort out the problem(s).
On Audio Tracks…
At this time I do NOT know of a way to make Dorico sync to an outside source. It might be possible, but I’ve not inquired about, nor stumbled upon such settings. If there were a way to slave up Dorico to MTC or something similar, I’m pretty sure Bidule could do it then. I’ll look further into it and see about explaining/demonstrating. I can however get Bidule, when hosted in Dorico, to stream a continuous audio track, stop and start with Dorico’s transport, etc.
No: Bidule does not natively support Video that know of. While I haven’t tried it, I see no reason off the top of my head why VidPlayVST wouldn’t work in Bidule.
You ‘might’ get some success with that syncing up with Dorico. Bidule as a VST might help host this plugin in Dorico because you could then at least get a MIDI signal of some sort from Dorico into the plugin. I’ll need to take a closer look at all of this…never tried it before…
On Creating automation data on controllers:
Specific examples of what you’d like to do would help, as I’m thinking of all sorts of scenarios of what you might mean by this…
Here are a couple of interpretations on what your question might mean…
If you wanted to take some CC event that Dorico is sending and transform that into an actual VST control directly for a plugin that is hosted in Bidule, then you could simply drop a little bidule into the network called “CC To Param”. From there, you can link that to whatever VST control(s) are hosted in Bidule. I.E. One of the Quick Control pots in HALion, or a fader of one of Bidule’s own mixers, or a ratio pot in a VST compressor-limiter plugin, etc. If it is a VST Control, you can certainly set up various methods to control it when hosted in Bidule. It’s also possible to use OCS to link controls among independent Bidule instances (even if they are not running in the same host, or even in the same machine).
If you mean to generate arbitrary streams of MIDI controller data…you can do things like create an LFO that would use a sine or saw wave to create a tremolo effect, or use a really low frequency saw wave and convert that into continuous controller messages to create a kind of ramp. It doesn’t have to be a sine wave…you’ve got all the standards, and you can even use your own wave-tables if you’ve got something truly unique in mind (It kind of reminds me of using the curve tool in Finale). If you’d rather do these sorts of effects to an actual audio stream itself (as opposed to working MIDI controls), then that is possible as well (I.E. build and manipulate a notch filter via LFO).
You could also trigger off small MIDI files, or use a ‘step sequencer’ bidule that you’ve made where you actually drew in the Controller events you wish to send. This is something I’ve done before when I wanted to fiddle with some parameters over a passage that one would normally just draw onto a controller lane in a tracking DAW. A good example might be creating a good sfz interpretation over CC1 or CC11. Since we don’t have such CC or Note Expression lanes in Dorico just yet…I can fudge them into a project by simply drawing them into a Bidule ‘step sequencer’ and having Dorico use an expression map technique to ‘trigger’ the sequence when it’s time to play it.
Another ‘trick’ I’ve used before to generate simple CC event inclines or declines (I.E. to gradually change the bow air or pressure over the course of a passage)…again since we can’t draw or record our own CC curves/ramps/etc. directly into Dorico yet…I have used native crescendos combined with an expression map technique to do this before. I know that Dorico is usually going to send CC1 or CC7 events in an attempt to play the crescendo/decrescendo; so, I can have a simple bidule network that given the right key-switch or Program Change, diverts those CC events and ‘transforms and rescales them’ into something else that I need.
If none of those scenarios are what you mean by ‘automation data on continuous controllers’, please feel free to lay out a specific example and I’ll try my best to interpret the question and give a valid answer.
What I mean by automation is, for instance, move the expression controller on a given track during playback and have it capture that controller stream for future playback. Or the volume control, etc.
Also, re: “not much to be buggy”… I downloaded the demo and it crashes every time I quit the program just perusing the existing demo layouts. Not a good indicator. I’ll accept that this might be completely related to my use of a Beta version of macOS. So I will be forgiving on this issue at least for a little while.
Yes, I believe you could do that by recording the MIDI stream inside Bidule. It doesn’t have an extensive MIDI editor for recorded MIDI files though (the step sequencer does (It’s like a diamond drum editor…I insert a little bidule that converts what draw in from notes to CC)…the step sequencer does not appear to be able to record live…I’ve always just drawn into it directly).
I’ve never tried it in a Mac. Is that on the latest version of Bidule? Are you trying to run multiple clients on the same audio device (I don’t know much about Macs, but this can be problem with Windows and ASIO drivers that don’t like multiple clients)? Is the sample and bit rate set the same across multiple clients? How does it act if you play around with Bidule and no other audio applications are running? Any feedback from Plogue (in forum or via email to support) on your issue?
It’s been a while since I have contacted them, but every time I have, they replied pretty quickly…on questions related to ARIA, Bidule, and Alter Ego.
Yes, latest version of Bidule. I don’t have anything else running. There is no mention of anyone running High Sierra beta on their forum. That is likely the issue, but none of my other audio software (and I have a lot of other audio software) has any problem with this version of the OS.
They might be highly interested in your case then. If I had a Mac, and more experience with the platform to compare notes I’d be far more helpful. Fire them an email and see what happens?
Brian, in the end it comes down to what you want to spend your time doing. From your posts here I get the impression that you find “using all the available technology” is an interesting activity in itself.
For me, it isn’t - I get plenty of that in my “day job”. (Though that sometimes reads across into interesting side-projects - like investigating the acoustics of some real acoustic instruments with test gear that “just happened to be lying around not being used for anything else” which would have cost more than most concert grand pianos to buy it just for that project…)
But given a choice between implementing some math by wiring together a rats nest of low level boxes written by Plogue that add and multiply individual numbers, or writing a few lines of C++, personally there’s no decision to make - the C++ wins every time. Once you have a working framework for creating a new plugin or instrument (which you can find easily enough from the web), changing the code that actually does some useful work isn’t very time consuming - and if somebody else has already built that functionality and put it on their web site, you don’t need to write any code at all, even if you know how!
Based on OPs posts, I gather he’s a developer of software and is quite knowledgeable about synth and sampler engines and libraries. He’s got two ears, a full tool box, and a creative mind. I don’t believe I’m picking on anyone who is anything less than enthusiastic about music world tech. I could be wrong, but that’s pretty much my frame of reference when I made a decision to mention things like Bidule and VEP, and how they can put you a few steps ahead of the development cycle when it comes to play-back power-user features.
So now that we’ve established that there is a significant difference in Bidule and VSTHost…in concept, design, and purpose, it would seem that now a visual/object based interpreter designed specifically for sound design is inferior to a process of re-linking and compiling executables; that possibly need a custom designed skins or other user custom interface tweak to grant access to that code is more efficient, easier, and less time consuming than a totally modular tool like Bidule; which actually makes all this stream level routing/transformation stuff really easy for ANYONE with a basic grasp of booleen logic to do? It makes more sense than taking a few moments to make visual bidules in an interpretive shell, that has all the tools all ready to bind any key or MIDI event to drive it on demand?
It really does not take me all day to connect a few little virtual cables and filter/route/transform/switch/automate things any way I like. Thanks to a tool like Bidule I can do it in seconds, then pack up the bidule and use it over and over again. It takes a heck of a lot less time than scattering a part over several staves, keeping up with the route a signal travels without a visual flow-chart, while trying to independently manage plugins in their own little isolated worlds during playback, and then trying to force it all to display and print as intended. Sonically, it’s actually pretty inspirational to be able to patch things around in a couple of clicks, and experiment with ideas and textures that otherwise could sprawl over dozens of tracks/staves, and take far more time and effort to try to manage natively in something like Dorico in its current state.
In contrast I find stopping an application, setting flags in make files, linking object modules, compiling or building executables, relaunching the application, and loading my session to the point I had it last to attempt to use it after an addition or change to be quite a hindrance to my musical work flow.
Perhaps it is easier for you to work from text editors and command lines to compile modules from scratch, or to stack 7 staves and mess around with renaming things until it shows up properly. Perhaps you’d rather make 4,000 line sound-set files in things like Sibelius and Finale (which often requires shutting down the Host and reloading the thing before any edits take effect) any time you want to teach them about a new Library. I personally beg to differ. I’d rather connect a few cables and click ‘learn’ in Bidule and be off to the races.
I’ve not suggested anything that people can not take for free test drive over reasonable amount of time and judge for themselves if it’s worth while. If the individual doesn’t like it, can’t make it work, doesn’t think it’s worth the money, etc…that’s all perfectly fine. They can work with what they’ve got, find other options, and wait for future releases.
Short of specific tips and tricks when using this tool to complement Dorico, I’m putting a lid on the Bidule advocacy in this thread now. I could drone on with all sorts of testimonies on how the thing has paid for itself many times over for me…but I think I’ve said enough.
While it’s impressive in its power and simplicity of design, I worry that the workings of Bidule’s processing nodes foil intuition. Trying to understand how the actual nodes work, and how they make one objective possible while they confound other mechanisms that worked just fine, has been rather challenging.
For example, in the example that I posted elsewhere, I ran the MIDI coming from Dorico through a Key Switch node, in an attempt to have muting and col legno battuto directives trigger changes to other channels (to which the appropriate sound samples have been applied in EastWest Play). While that worked, it resulted in keyswitches defined in Dorico but not defined in the Key Switch bidule being ignored (i.e. not being sent to the Play VST), with the result that my violins play only col legno battuto or muted samples. So now I have figure out how to rig everything such that I’m not forced to choose between Bidule’s Key Switch node and the keyswitching offered in Play. (It may not even be doable, for all I know.)
I really need to spend several days just educating myself on how assorted Bidules work. As I wrote, they have not come across as very intuitive to me. Some functionality works as expected, other functionality has been quite puzzling.
I’ll take look at the link. I think I get you sorted, but at this point it sounds like all you need to is to use two key-switches in different ranges from the expression map. Another option could be using a CC or PC to do channel hops and leave key_switches for internal EW switching.
CC or PC is precisely what I was planning to look into, instead. That just seems like the logical way to go, especially PC which I’m not using at all, and don’t foresee using.
I just have to figure out which nodes (Bidules) support the functionality that I require.
I threw up a screen shot here:
Here is a bit more detail on this question:
I fidded with VidPlayVST in Bidule for a few minutes. In this case there is no advantage to running it in Bidule. In fact, in Dorico it looks and resizes better if I do NOT run it in Bidule. I just added it to the Dorico Whitelist and tried it directly in a Dorico instrument slot. It syncs up pretty well with Dorico in either case (from Bidule, or Directly in Dorico). As for forcing Dorico to slave to Bidule (or any other Master clock source), I don’t see a way so far. I don’t think that is possible just yet. So…locking Video to Dorico for a mere $15 is definitely possible, but Dorico has to be the Master.
For syncing audio tracks that are running in Bidule (as a VSTi) up with Dorico:
Now the audio track is locked in sync with Dorico. It follows the Dorico transport/playback cursor.
it won’t work with stand alone Bidule until Dorico can send a clock over MIDI, or do ReWire, or unless you have some sort of plugin that can leech the sync signals and pass them off to Bidule somehow.