Conquistador's Forum Page

@CymaticCreation wrote:

This can be very troublesome for people making collaborations, mobile users, those with more than one machine, the list goes on and on…..

Agreed.

It has been a problem for me for a very long time. I know Frits to be fair has had many other FR’s (many of mine as well as others) that he has implemented in the past but hopefully he can re-visit this FR. I also brought it up previously on this thread.

He has done an amazing job trying to implement user requests (sometimes at very short notice) over the years. I just hope he can slice out some time for this FR 🙂

Frits some observations…

When I wanted to drag in another instance of Omnisphere (Global instance) I got the Error message telling me it is already active on another track. I normally don’t use more than one global instance of say Omnisphere or Trilian but…for the sake of testing Px64 out, I thought I would try. I was a bit puzzled about this but of course there are up to three options that will give me what I want (right clicking on the mapping from the project page listing), it just depends what I want to see in a new plugin instance. 😉

At track level
The only problem I see with this at track level where the error will appear is that a new user will not likely figure out how to solve this problem themselves. I would suggest if possible to add a prompt or additional text to the error message that pops up in the arrangement view that might say…

“This mapping is already active on another track would you like to create a new instance?” With a simple OK / Cancel button option to choose from. Yes you can right click the instance in the inspector but…I was scratching my head for a bit. 😛 That additional text / prompt would snap in /lock the user experience in nicely. No need to sit wondering what that error means and or how to solve it :-k

A few other things…

1. The ZPEQ did not scan (after a previous successful scan) and crashed Podium but…when I attempted a re- scan there was no issue. I removed it from the quarantine list first. Works fine inside Podium.

2. I got a few messages about J – Bridge not being able to run as Podium is not being run as an admin. This popped up as a result…

“MLSemaphore…” I think is dev speak for “Yikes this code door needs to be closed asap?” 😀

Once I changed that (admin rights) there was no problem. Not seen that pop up since the admin change or any other warnings about J- Bridge. All in all…great work Frits 8)

Update…

Multiple Ozone 4 inserts with all six modules running on different tracks. I might try stacking them on the same tracks to see what happens 😛 Really…this is beyond what I would use Podium for. Hopefully more obvious things have not slipped through my testing net. With time permitting I cannot test everything but so far so good.

Pushing 70% CPU now…Podium is still holding up. Saving and tweaking during playback tweaking just dragged in Lounge Lizard… 😉

Might drag in a second instance of Omnisphere with 16 outputs and and 16 Midi inputs should I even be allowed to do that? 😆

Audio Clip volume adjustment, fades all holding up…realtime MIDI editing…all good.

Will try some automation….and push to 80% or 90% of CPU >gulp< 🙂

Beta 3 x64 testing….

I did have a crash with Geist…but I am yet to repro that after multiple efforts to reproduce the crash. But I will certainly let you know if I can reproduce it.

I am running a project (with native x64 plugs) that scales to about 30% of CPU but is running the Beta 3 x64 zPlugs, all three Spectrasonics plugs, Geist, Rapture, Z3ta+, Ozone 4, Sugabytes Turnado (add that to the list of tested x 64 plgus here), U-he Tyrell N6, AAS Ultra Analog, Inpdependence 2.5 e.t.c

I am basically trying to work far beyond the way I normally would to try and see if Podium will do something it should not. To be honest considering most devs are likely to test their plugs with the major (or better known hosts out there instead of Podium) hosts, it is quite an achievement that I can use Podium this way it can remain crash free.

So far so good here. I may have missed bugs that might appear in a different workflow but so far it appears pretty solid. Export / Render appears OK as well.

Pushing the project further up CPU wise to see what happens…

Looks the Rapture update solved the crashes with the plugin. :-k So far so good. 😉

Happy to report Geist x64 and Yellow Tools Independence 2.5 x64 also appear to run fine in Px64. 🙂

Results Summary…
Very smooth. No drama here. Had one incident where changing a patch in Trilian resulted in a glitch but to be honest it is probably not advisable to switch patches in such memory intensive plugs in real time with about 6 other VSTi’s running at the same time at a latency of about 4ms or less. 😉 🙂 Some of the Trilian patches take a bit of time to load I am guessing Trilian had not fully loaded the patch. Not able to repro the issue in any case.

Smooth sailing so far. I think Geist now has an official X64 version (out of beta) so I will give that a run out in 2.43 as well as any other x64 plugs I do not have any more time to test today (Yellow tools Independence is another). Will probably post back tomorrow on those as these tests took much longer than I thought for today 😛