Trivia …
I did the solo on an SH-101
My hardware gear…
Live
- Yamaha EX5 (brilliant master keyboard, and still a few sounds that I cannot get from elsewhere
- Korg Kronos - the modern day successor to the EX5 IMO. This now provides the bulk of my live sounds (until I get my VSTs onto Cantabile on PC).
- Roland FC300 Midi Foot Controller - allows you to do all sorts of things whilst your two hands stay on the keyboard!
Studio
- Yamaha SY99 - the pinnacle of Advanced FM. Mine is maxed out to a whopping 3MB of sample RAM courtesy of Sector101 after market cards. Myself (software) and Brian (hardware) of Sector 101 have also hacked the Wave Card format to get another 2MB of sample data into the SY range!
- Yamaha TG77 - yes, I know I have an SY99, but the SY77/TG77 have a grungier character that is sometimes more appropriate!
- Yamaha AN1x - still one of the best analog VAs ever IMO.
- Yamaha FS1r - not one I use much, but whenever I want something different, this is my go to rack
- Yamaha Motif Rack ES - I am not really a Motif fan (this is where Yamaha starting dumbing down IMO) but it does sound nice. I purchased it as an expander to my EX5 to counter EX5 performance mode limitations, and I have expanded it with PLG150-AN and PLG150-VL cards.
- Nord G2 Engine - my “go faster stripe” in my rack. An amazing modular synth in a 1U rack!
Very Impressive, i especially like the Kronos wish i had one.
Dave
Thanks, it is a carefully selected line up of Yamaha classics before they went boring, and the Nord is my wild card secret weapon! A huge shame they stopped doing the G2.
Re the Kronos, this is my first Korg and I went for it after giving up on Yamaha ever doing anything interesting again! The 40th anniversary Yammie synth being a Motif in a white paint job was the last straw. I really like the Kronos, it is well thought out combination of 9 sound engines in a really nice packaged user interface. Features like Smooth Sound Transition are a huge bonus on stage. As I say, I see it as the modern day successor to the EX5 and the multi engine synth concept.
Absolutely, they’re fantastic - I have three of the things, two in my live rack and one in my home studio. Lovely bit of kit and incredibly versatile. As you say, shame they stopped doing them.
If you see one second hand, buy it…
Neil
Aah! I always forget about the jBridge trick!! I just tried it, and Diva dropped from around 30% load to about 7%, with the same patch.
Thanks Ade!!
Neil
Ok, I’ll be the first to admit ignorance - what on earth is the jbridge trick?
Terry
Careful Terry, these two may be laying a trap for you! lol.
UHHHH, BTW, what is the trick? Wincing
@terrybritton
Brad could probably answer it better detail but Joao is doing tricks when the library is being loaded so that the host has more resources available than it usually would after loading the plugin.
He off-loads the thing to another ‘program’, auxhost.exe. He doesn’t give much away but he might be using COM (the way Excel and Word talk to each other)
He must be doing something right because some of the big DAW guys have built-in support for it or have built their own lawyer protected ‘version’.
You can also mix and match 32 and 64 bit plugins.
Worth a look.
It’s not anything too tricky - there’s no free lunch!
What jbridge can do is allow you to place an additional buffer into its path.
All of us are trying to get the lowest latency, reliable, performance. A hog like Diva could make it tough to run the rest of a setup at super low latency. Jbridge’s ‘performance mode’ targets the one plug in, doubling the current ASIO buffer.
So, if your system is set to 64, jbridge can run a plugin at 128, and lower the demand.
128 becomes 256 etc.
Still totally playable without sacrificing the entire setup.
I believe jBridge also runs the plugin in a separate process, and the extra buffer is dedicated to that plugin, rather than sharing, which is why it can be helpful for plugins that show high load values.
But I think I remember Brad saying jBridged plugins don’t contribute to the displayed load values, which is why the drop in load can be dramatic. The danger is that you’re running a plugin “blind”, with no visibility of it’s own separate load, or whether it’s hitting close to 100%.
Exactly - you need to watch for loading outside of Cantabile.
However - an extra buffer is an extra buffer and if you watch the system performance meter with jbridge perf mode on or off, you see that you’re winning when running diva this way.
@Ade @Neil_Durant This is very cool info guys…thank you so much for sharing this. I took the plunge and downloaded Diva last night. Omnisphere is just around the corner.
Good to see another G2 fan. I purchased mine for £400 in 2006, and have seen them going for £1200 now, but I will never sell mine.
It is funny, when I used to gig it (before the Kronos), a lot of musos would want to know where I was getting my lead sounds from. When I pointed out this bright red 1U rack with two LEDs and an on/off switch for a user interface, they were stunned. With the Kronos and AL-1 I have managed to reproduce my G2 Floyd leads to the point where they are good enough, but different. But I think I still prefer the character of the Nord. It’s just that taking out less wins me over these days, which is where the Kronos scores (as will a laptop and Cantabile and a pile of VSTs when I get time to set it up!).
Although I haven’t had much time with it yet, I got Zebra for Christmas and am very impressed with it. I can see myself getting more UH-E soft synths.
I believe jBridge also runs the plugin in a separate process
It does in deed. The other host is named ‘auxhost.exe’ and basically a ‘pipe’ between Cantabile and auxhost.
One can use COM or even TCP/IP to connect the two hosts programs. In a similar manner to using Maple midi etc to connect a sequencer program to Cantabile.
Naturally the combination of Cantabile and auxhost uses more overall system resources than Cantabile loading the library directly. However there are advantages to be had that offset this.
I’m not too familiar with the inner workings of jBridge however I would guess the trick here is the extra layer of buffering.
When unbridged the entire plugin processing needs to be done within the current audio cycle.
When bridged, the inputs to this audio cycle are passed to the plugin but it doesn’t need to wait for the output because instead the outputs from the previous audio cycle read back and become the output of this cycle. ie: on the host side there’s no “inline” processing of the plugin it’s just the communication to the separate process. So long as the processing is finished by the next cycle it can take as long as it likes.
But… the output has one audio cycle extra latency (and no visibility into how long it’s really taking).
It sounds like magic, but in reality it’s bit of “smoke and mirrors”. You’re better off running in-process when you can because there’s more work in running the plugin bridged (the overhead of those cross process calls) and that processing overhead needs to come from somewhere.
He doesn’t give much away but he might be using COM (the way Excel and Word talk to each other)
I helped Joao a little with the early versions of jBridge and while I can’t remember the details it didn’t use COM back then. Pretty sure it’s built out of regular synchronization primitives like events and shared memory.
Oh dang! How could I forget the Korg 01/W! That was my absolute main board for pretty much the 90s. Anyone heard the story that it was actually supposed to be the M/10 but they silkscreened the protoype upside down?
That makes a certain sort of sense!