Issue with 32 Lives and DP 8.05

[James Steele]

Okay... I'm gonna call this:

32 Lives Digital Performer plug window STRANDING

(As is STRANDED like the castaways in Gilligan's Island.)

Below is a movie of what's happening. It has happened in LiquidMix and Slate FG-X and I suspect it's going to happen for all bridged 32-bit plugs. Can others confirm?

If you watch the movie you can see that first that when I drag the plug around, FG-X's GUI lags behind. That's cosmetic and something I could happily live with. I think this is due to the fact that (like jBridgeM) the developer is hosting the plug in his own hosting app called "32 Lives" which is running in the background. Note that when I click FG-X to load another preset, you'll see the menu bar at the top show I'm switching to the 32 Lives app.

When I come back to DP everything seems normal. DP's window bar is still above the FG-X GUI. But then watch when I bring forward the Track Overview window by clicking on it's title bar. FG-X's title bar disappears and now the window is stranded with no way to move it or to close it. (Command+W does not work, and trying to cycle through windows with Command+~ doesn't work either.)

I had thought previously the only way to clear this up would be either quitting and relaunching DP then loading the project, or removing the plug in's instance at the mixing board by selecting it and deleting it, then reistantiating. But then the answer to where the missing title bar went occurred to me and I had to make a new screen capture. Notice at the end of the movie, I select the Track Overview and move it down, revealing the title bar of the FG-X plug which is damned to an existence forever as the bottom-most window in DP! LOL

However, now there's a work around... in my case I move or minimize the Track Overview window to reveal the FG-X title bar, then close the plug, then bring the Track Overview window back. On next open of FG-X it will be normal again. Seems the moral of the story for now, until this is hopefully fixed, is make your adjustments to your plug in and keep the window in the foreground until you're done adjusting, then CLOSE it before switching to a window that will cover the plug.

[MIDI Life Crisis]

Funky! While I can't help with that, I will once again remind people that, IMO, Plogue Bidule is the way to go with bridging both VSTs and AUs. That comment always seems to get ignored, which I find fascinating since it works well and has a bunch of other features that the other bridges don't.

But y'all can continue to... and while PB users and

[James Steele]

Funky! While I can't help with that, I will once again remind people that, IMO, Plogue Bidule is the way to go with bridging both VSTs and AUs. That comment always seems to get ignored, which I find fascinating since it works well and has a bunch of other features that the other bridges don't.

But y'all can continue to... and while PB users and

hahaha... I'll have to try it again! LOL Last time I looked at Bidule, it seemed rather cryptic.

[MIDI Life Crisis]

It IS a little cryptic until you get the hang of it. DP was the same way for me... LOL!

The key ingredient is Rewire and activating it properly. Frankly since running DP in ML and now Mvrks in 64 bit I've not needed PB as all my plugs are now 64 bit. If i needed MX4 I'd probably just boot DP in 32 and not bother with PB, but if I HAD TO bridge again PB would be my choice, for sure. And PB has so many other features and routing options I still use it, but for Finale exclusively now.

Again, I've not used PB in ML or MV (I'm gonna start using MV for the abbreviated OS name from now on - I like it!).

[James Steele]

I guess part of why I avoid it, is I'd like to have the illusion (as much as possible) is not having to interface with another application and not have DP projects with dependencies on another application to run. Of course the bridging solutions are just that.

Hopefully this "bridging period" is just a transition, and if some plugs are never updated, suitable replacements or reasonable facsimiles can be found. Perfect example in my own world: BetaBugs MonstaChorus. It's a freebie you can get from this page here:

http://www.betabugsaudio.com/plugs.php

I absolutely love this plug on guitar. I captures some of the mojo of my old Electric Mistress pedal that all other plugs don't seem to do. The Electric Mistress was far from "transparent" and even rolled off some of the bottom end of what was coming into it, but it had a great sound. MonstaChorus nails it for me. MOTU's Analog Flanger (which was based on Electric Mistress) comes in very close.

It really makes me wish I knew how to program and had access to the source code. I have a few old plugs that appear to be doomed to the 32-bit scrap heap and it would be a rewarding labor of love to be able to bring them into the 64-bit world so we all could continue to enjoy them without kludges like "bridging" apps.

On last point: All these issues drive home the wisdom of MOTU deciding to pass on implementing a bridge within DP. Not unusual for them to make the right decision early on. Look at Logic Pro X. They gave up on built-in bridging from what I've heard. Logic Pro X is 64-bit plugs or nothing. I don't know, but I'll bet you can't launch it in 32-bit mode either?

[James Steele]

The key ingredient is Rewire and activating it properly.

Arghh... you scared me right there. I get nervous about internal routing software like Rewire. Viscerally. Can't say it's justified, just fessing up.

I, too, can't wait to make the leap to Mavericks. I got Mountain Lion today and so happy to have my ONE DAY with Lion as a memory now. Like this much better. I'd be on Mavericks today if not for the issues with the PCI MOTU audio interfaces and kernel panics, etc. MOTU has a programmer dedicated to this issue from what I've heard, so I'm hoping I can make the final jump soon. Maybe next week if we're lucky. Can't wait to see a new PCI Audio Installer on the MOTU site!

[MIDI Life Crisis]

And that's the trades off. Launch in 32 and loose higher RAM access or launch in 64 and compromise plugs that haven't caught up yet. It will all iron out eventually and for some of us it already has. I don;t use a lot of plugs for processing and prefer a less processed sound. My major concern is VI access and in that regard the only sluggard left is, ironically, MX4!

[James Steele]

And that's the trades off. Launch in 32 and loose higher RAM access or launch in 64 and compromise plugs that haven't caught up yet.

Yeah... well I will say this, though. Launching DP8 in 32-bit mode feels like less and less of an option to me. DP 7.24 seems better suited to 32-bit operation, IMHO. In fact, I just advised a friend today to stay on 7.24 until he knows he wants to go to 64-bit. Projects that I used to open and run fine in 7.24, make me nervous in DP 8.05. DP 8.05 has a memory meter that appears when it is launched in 32-bit mode and often it is PEGGED in the red on projects I ran just fine in DP 7.24. It doesn't seem to result in audio glitches, but it freaks me out. The processor meter seems to read higher too. Then, if you launch DP in 64-bit, the processor meter reads lower and DP seems to breathe. I really feel DP 8.05 is a creature of the 64-bit world and it should be run that way. If you're going to live in 32-bits for a while longer, stay in 7.24.

64-bit is where it's at now and I'm working on updating my projects so I can work exclusively in it. That's how shaky I feel using DP 8.05 in 32-bit mode.

[MIDI Life Crisis]

I've been running DP in 64 ever since day 1 of DP8 and never looked back. I too ran DP 7 as a trial after that and agree, it seemed like it just wasn't "right."

No app will ever be "perfect" but as long as it does what i need it to do, I'm happy.

[waterstrum]

Yeah... well I will say this, though. Launch DP8 in 32-bit mode feels like less and less of an option to me. DP 7.24 seems better suited to 32-bit operation, IMHO. In fact, I just advised a friend today to stay on 7.24 until he knows he wants to go to 64-bit. Projects that I used to open an run fine in 7.24, make me nervous in DP 8.05. DP 8.05 has a memory meter that appears when it is launched in 32-bit mode and often it is PEGGED in the red on projects I ran just fine in DP 7.24. It doesn't seem to result in audio glitches, but it freaks me out. The processor meter seems to read higher too. Then, if you launch DP in 64-bit, the processor meter reads lower and DP seems to breathe. I really feel DP 8.05 is a creature of the 64-bit world and it should be run that way. If you're going to live in 32-bits for a while longer, stay in 7.24.

64-bit is where it's at now and I'm working on updating my projects so I can work exclusively in it. That's how shaky I feel using DP 8.05 in 32-bit mode.

I agree!
I've been a hold out for 7.24 and recently opened some of those projects in 32bit 8.05.
I definitely got the feeling that 7.24 was handling things better.
I have several projects that are nearing completion and will stick with 7.24 for those.

That being said, I've started making new projects in 64bit 8.05 and wow!
It is a whole new world for quick loading and much higher headroom when using lots of plugs and VIs.
I'm thinking it will be hard to go back.

I'm missing quite a few legacy plug ins and VIs, some of which will not be updated to 64bit.
I share your resistance to using rewire and some kind of bridge.

I'm testing Bidule and so far it seems pretty cool.
I hate to have to launch and configure another app to be able to do projects.
Seems like another layer of possible problems.
Nice to have the old stuff available, though.
Time will tell.

[Shooshie]

That being said, I've started making new projects in 64bit 8.05 and wow!
It is a whole new world for quick loading and much higher headroom when using lots of plugs and VIs.
I'm thinking it will be hard to go back.

When people ask me about 64 bit DP vs. 32 bit, I say to move on up to 64 bit. It's inevitable, anyway. The plugins that aren't going to be updated are dinosaurs, and you don't want them to make you a dinosaur too. Just ditch them, find something better, and get out of 32 bits. Life's too short to go deeply into obsolescence for the sake of a plugin or two, especially when there are almost always others that can do the job. I didn't want to leave Miroslav Philharmonik, but it is the oldest orchestral VI around, and it keeps coming back. I'm quite sure I'll have another chance to use it if I want to in the future, but I'm not going to sit here waiting on it. In fact, I've almost forgotten it. I went 64 bits as soon as it was possible, and I haven't looked back. I had to let go of my Elemental Audio meters, but I found Blue Cat meters, which are 10 times better. It's been that way about everything. There's always another —usually better— one out there if you look for it.

The move to 64 bits brings us into a new age of computing power and memory. There's no need to wait.

Shooshie

[James Steele]

The plugins that aren't going to be updated are dinosaurs, and you don't want them to make you a dinosaur too. Just ditch them, find something better, and get out of 32 bits.

I hear you, but I do have one or two that I like and if I can use a bridging app to continue to use them, I will. Until I find something better or at least comparable.

[Shooshie]

The plugins that aren't going to be updated are dinosaurs, and you don't want them to make you a dinosaur too. Just ditch them, find something better, and get out of 32 bits.

I hear you, but I do have one or two that I like and if I can use a bridging app to continue to use them, I will. Until I find something better or at least comparable.

Bridging is another matter. It's inconvenient, but if you see an end to it (the plugin will eventually be updated to 64 bits) then it's just a matter of patience. I use FG/X under a bridge, but I do know that Slate will be updating it. I don't know what I'd do if Slate said that FG/X would be remaining in the 32 bit domain. It's too good to leave behind, but I might have to look around and see if anyone else has gone in that direction and made something similar. It bothers me to have to switch in and out of DP to use the plugin. The transport controls won't patch thru the bridge host, and when you're doing a lot of experimenting, that can really be a drag. But if Slate is good for his word, I won't have to use J-Bridge much longer.

Anyway, yeah, I understand the need to bridge those plugins that you need. I just hate to see anyone stay in 32 bits for those plugins when they CAN bridge them into 64 bits. I've never experienced such a long stretch of smooth operation in DP as I have since it went 64 bits. Version 7 was great, but all the versions since then (excepting the brief-lived 8.0) have been amazing for me.

Shooshie

[James Steele]

Bridging is another matter. It's inconvenient, but if you see an end to it (the plugin will eventually be updated to 64 bits) then it's just a matter of patience. I use FG/X under a bridge, but I do know that Slate will be updating it. I don't know what I'd do if Slate said that FG/X would be remaining in the 32 bit domain. It's too good to leave behind, but I might have to look around and see if anyone else has gone in that direction and made something similar. It bothers me to have to switch in and out of DP to use the plugin. The transport controls won't patch thru the bridge host, and when you're doing a lot of experimenting, that can really be a drag. But if Slate is good for his word, I won't have to use J-Bridge much longer.

Anyway, yeah, I understand the need to bridge those plugins that you need. I just hate to see anyone stay in 32 bits for those plugins when they CAN bridge them into 64 bits. I've never experienced such a long stretch of smooth operation in DP as I have since it went 64 bits. Version 7 was great, but all the versions since then (excepting the brief-lived 8.0) have been amazing for me.

Oh yeah... I've decided it's 64-bit for me and I may just bridge the few plugs that I need to. I have a couple of plugs that I really like that probably won't be updated, but if the bridging method is transparent enough, I can live with it. One of my favorite 32-bit dinosaurs, MonstaChorus, is something that's largely "set and forget." I have a basic sweet-spot setting I use most of the time. I can instantiate it and pretty much leave it closed, making switching out of DP to the bridging host unnecessary.

You mention jBridgeM, which I've been using up to this point. It can't be beat for value. However, I recently purchased 32 Lives beta now that I have a Mac running a current enough OS, and it seems to have the potential to be a more polished and robust solution. I'm cautiously leaning toward 32 Lives at this point. The developer emailed me in response to a bug I reported, stating that MOTU has been very supportive and supplied him with DP8 to test with, etc. He seems serious about addressing issues affecting DP8. He also said he joined this forum and will try to comment here on issues that crop up. I find that VERY encouraging, as I was afraid he might be coming from a very Logic-centric perspective and not be that concerned with DP8 issues.

Oh.. just remembered this: as far as FG-X goes, one thing that jBridgeM has is a "Performance Mode" checkbox (or something to that effect) that when checked noticeably reduces the considerable hit FG-X has as shown in the processor meter. I don't know how it achieves this. Nor do I know whether it's really more efficient than 32 Lives. And as you pointed out, FG-X is slated (no pun intended) for a 64-bit update so it's all academic. I am pleased that Steven Slate mentioned that they are rewriting it to make it more efficient and reduce its considerable hit on the CPU.

[James Steele]

I'm happy to report something I just discovered. I don't know how it does it, but 32 Lives is passing keyboard transport controls to DP while I have a bridge plug-in GUI active. It shows 32 Lives as the foreground app in the menu bar, but spacebar is starting and stopping transport and I even used the "." and the measure number to locate to a measure.