Thanks Frits. 🙂
@Zynewave wrote:
Beta3 is uploaded. There are a lot of bugfixes and extended error reporting. This hopefully is the last beta, and the final 2.02 will be released this week. Please let me know if you find problems with beta3.
Mentioned earlier but it’s has come up again…closing a Project (not Podium) before closing a Rewire slave (in this case Project 5) results in this error which might not provide enough information for a user. It also looked a bit vague.
Interestingly Reason auto closed even when I closed a Project I was using it in. P5 did not. I would have thought it would be a user action but an auto close for Reason (at least) is even better. Maybe P5 auto closes (if a project using it is closed) on x86. If so then it’s maybe a native x64 limitation of sorts that P5 has. Although Reason is not x64 native yet either, but then again Rewire is part of Propellerheads so it is maybe more likely to work better with Reason I guess.
@Conquistador wrote:
Hmmmm P5 does not start up automatically when using the “Import Rewire devices command” but it will auto start after dragging the mapping to a track in a new project.
The ReWire dlls are not opened when using the import command. It’s only when assigned to a track and power is on that the devices and their panels are opened.
Sorry Frits what I was trying to say was *after*…importing Rewire devices (into an existing project) and dragging the mapping to a track, that P5 does not autostart. It did in Beta 2 with a new project and now it auto starts after an import into an existing project and with new projects so whatever changes you made solved that problem completely.
Once imported into an existing project Reason and P5 both showed up instantly but…when I dragged P5 to a track in Podium it showed this error…
…again it had no bearing on the functionality of Podium, Reason or P5 but the error was there. I could and did open the Rewire devices succesfully.
I’m not getting that error with the P5 demo. Maybe the error only occurs on Vista 64 bit OS.
I have not seen that error in Beta 3.
Quick note..
Rewire Mappings are still labelled as FX in Beta 3.
R for Rewire might be better instead IMO, unless you specifically want them to have the same label as FX mappings which I think is a bit confusing. Rewire slaves are usually Hosts (Live, FL Reason, Reaper, P5), I think some are instruments but I am not aware of any FX that are accessible as Rewire slaves. In any case I think R for Rewire might nicely side step possible confusion with mappings. Just a thought.
Nice addition (below) that makes things clearer. Not sure if it was in Beta 1 or 2 but it certainly works in Beta 3.. 🙂
@UncleAge wrote:
@Conquistador wrote:
Maybe some sort of warning (that floats on top of any existing windows) can alert a user to “please close existing Rewire devices before opening another project”. Also maybe not even allowing a user to open a new project until they have closed open Rewire Devices, I think some other hosts operate that way….with a short warning.
Is there a way to send a Rewire slave an auto close command from the Rewire master?
There may be a way but I do not know of any host that does that. Maybe Frits could do it but I assume that as no other host (AFAICT) auto closes a Rewire Slave, then Frits will very likely also as some hosts do…prompt the user to close the Rewire Slave first.
I think Tracktion, Sonar e.t.c prompt users to close Rewire slaves first…at least when closing the Rewire host, I think prompts also show up when closing projects IIRC.
@Zynewave wrote:
I tested Podium with Reason adapted (an older version). It picked up Reason ok, but whenever Reason would get to the end of a loop it would hang during playback. It’s like It would not loop at all, even though moving the loop points in either Reason or Podium were always in perfect sync. Playback in Podium carried on though.
Please try this again with the new beta2. I’ve made a change that may fix this looping problem.
Fixed now! Reason Adapted now loops properly!
I noticed that Reason did not start up automatically after I dragged the Mix mapping for it to a track, is this a Reason limitation?
The Reason 4 demo I’m using opens up automatically.
Still not getting that here. Might be something that will work on a fully Propellerhead supported platform i.e Vista x86. I don’t think Reason 4 is x64 native yet. My version is quite old.
The beta2 has a new “Import ReWire Devices” command in the devices menu on the start page.
Very useful addition. Just simpifies things a bit thanks.
Hmmmm P5 does not start up automatically when using the “Import Rewire devices command” but it will auto start after dragging the mapping to a track in a new project. Once imported into an existing project Reason and P5 both showed up instantly but…when I dragged P5 to a track in Podium it showed this error…
…again it had no bearing on the functionality of Podium, Reason or P5 but the error was there. I could and did open the Rewire devices succesfully.
Maybe the error is why P5 did not start up automatically when imported into a project. The error also shows up when using P5 in a new project but P5 still auto starts anyway. It will *not* autostart if the Rewire mapping is imported though.
Not sure how far you can take this as I am on x64 so it might be something to do with that. Some x86 feedback would perhaps help you more. Just trying to avoid you chasing an issue that might be more to do with x86 apps running on an x64 OS. But if you have an idea why the error is there I can have another look with a new beta or try something else to see what is wrong.
The mono channel labels come from the ReWire devices. In beta2 I’ve changed the way I combine mono labels for stereo pairs. E.g. “mix” will now read “mix L+R” etc.
Thats excellent thanks!
Furthermore in beta2:
• Record-enabling a ReWire MIDI mapping track will record parameter tracks of control changes made in the ReWire device window, provided that the ReWire device supports MIDI output.
That new feature worked very well when I tested with Reason adapted. I could not get it work with Project 5 though. It may be I need to configure P5 a different way. In Reason I simply dragged the Mixer Midi mapping in Podium, hit record on that track, moved the mixer fader (in Reason) and Podium recorded my movements. Easy.
Maybe I am having problems getting the same result as Reason because Project 5 is not exposing its Midi mappings the same way as Reason, …not sure. P5’s Midi mappings are coming up as “channels” in Podium so in theory it should be easy to line them up with P5 I guess. I’ll have to try that one again I might be doing something wrong here.
You can get the P5 demo from here (untick the two boxes at the bottom of that page) if you want to see for yourself what the problem is. My description may not be coming across that well sorry. It might be user error on my part. It’s probably not a bad idea to download the demo as it will almost certainly help to get a better idea of how Rewire clients can differ even if It is user error on my part. 🙂
Some other observations…
1.The usage of bounce tracks will surely increase with Rewire in Podium I was constantly using them to bounce results from P5 and Reason even at the same time. But…the first thing I noticed was that I had to manually create an object first. Most people will not know that. Problem.
It might not be a bad idea to alert the user to “please create a blank object for your data with the Pencil tool” as soon as a Bounce track is created. Or even much better, auto create an object on new bounce tracks as Podium already does with the Starter Master track.
Having come so far with Rewire you do not want to ‘lose’ a demo user at that crucial point.
2. When I closed a Podium project that had P5 still mapped to it and P5’s arranger still open, Podium allowed me to close the project. When I maually closed the P5 app…I saw an error “Rewire Device closeout” I think.
Maybe some sort of warning (that floats on top of any existing windows) can alert a user to “please close existing Rewire devices before opening another project”. Also maybe not even allowing a user to open a new project until they have closed open Rewire Devices, I think some other hosts operate that way….with a short warning.
With arrangements this may also be necessary to avoid confusion.
Initial test feedback…
Finally! It fits in rather nicely if I may say so 🙂
I initially tried to find the Rewire entry (after a scan) in the Devices column and could not find it in an existing project. Perhaps an x64 Rewire Vista limitation I thought 🙁
I then tried to start a new project and Podium did add a Rewire folder this time (yes!) I tested Podium with Reason adapted (an older version). It picked up Reason ok, but whenever Reason would get to the end of a loop it would hang during playback. It’s like It would not loop at all, even though moving the loop points in either Reason or Podium were always in perfect sync. Playback in Podium carried on though.
I guess it might be because I am using an older version of Reason (2.5), so maybe that is why. I guess a Reason 3 or 4 user would need to give feedback on that for us (please). The version of Reason I am using is not x64 compatible FWIW, but it works fine on it’s own on V x64.
Start up for Rewire hosts
I noticed that Reason did not start up automatically after I dragged the Mix mapping for it to a track, is this a Reason limitation? Project 5 for instance satisfyingly did start up automatically as soon as I dragged one of the available Rewire mappings for P5 to a track but as soon as it did I got this error….
Error 5?????
Funnily enough though everything AFAICT still worked perfectly. I heard the output, adjusted loop markers in both apps and they synced perfectly. No drop outs, or glitches. So the error appears to have no bearing on performance or anything / where else. Any idea why that error is showing up?
Also there is a link to an updater for Rewire apps on Vista (x86 only almost certainly)
I downloaded it and installed it on x64 anyway just to see if it would remove the error…and it did. At least for now. I started a new project and the error was gone once I installed the Rewire Vista update from Propellerhead. So maybe that was the cause.
Naming convention for Rewire Mappings
The channel mappings for Rewire hosts are labelled as FX. Surely that should be i for instrument or for even better and easier classification, how about R for Rewire?
I set Project 5 to only show one Rewire output and it showed up in Podium as L.
It played as a stereo pair though correctly but I just wondered if that was Project 5 exposing the listing / mapping that way to Podium or Podium not listing the stereo pair properly.
Reason main outs appear as “Mix” to further rmuddy the waters. 😛 I am guessing it is the applications that are causing the disparity with the naming of outputs but I am not an expert on ReWire so you tell me. 😐
Bounce test
I successfully bounced a track from Project5 in realtime and dragged the play cursor to a new starting point all in realtime with no glitch, super smooth. I switched back between the Project 5 output and the Bounced output by clicking the B button, no problems there either. Super Slick.
The big one… Merge project test…He he…
I used the Merge project command to add the Rewire mappings to an older project. It was an instant process. No problems using the Rewire Mappings there either. Bear in mind this is all working on x64 Vista which is not even officially supported yet! Impressive.
Back to Merge project though…how else would a user add Rewire devices to an older project? Is Merge Project the only suggested way? Or do you have something else in mind to add there? Works perfectly well and is instant FWIW.
It has been quite an experience combining rewired apps with Podium. It really does take things to another level. Brilliant. So far so good here.
Nice!
I hardly use Rewire personally but it’s importance to Podium is simply huge. A massive addition that now opens up a new demographic to Podium…
Reason users
Ableton Live users
Reaper users
Project 5 users
e.t.c
Adding Rewire also seriously swells Podiums clout for future reviews. It would have been marked down for the lack of it. Heading the right way Frits. Well done! 🙂
Not sure if I can use Rewire on Vista x64 (should be able to though, between x86 apps) but I willl post back to let you know. I would certainly like to help by testing the 2.0.2 Rewire beta for you.
@acousmod wrote:
Exhibit B: More detail inVST or VSTi GUI headers
Yes…
http://www.zynewave.com/forum/viewtopic.php?t=1492&highlight=plugin+track+name
Heh Heh! You beat me to it. 🙂
@UncleAge wrote:
Another case for reduction in clicks is tempo changes. I’d like to left-click+drag to change the tempo instead of opening a dialog box. And a modifier key for finer adjustments would be welcome as well.
Good one yes! IIRC I think Logic, Live and Cakewalks Project 5 e.t.c allow this. A nice addition to further reduce clicks, definitely.
@acousmod wrote:
You are right, BUT.
My feeling is that if a car constructor has to show flashy warnings saying that “you have to press this button before turning the wheel to the right” or “don’t remove your left hand while you slow down”, there is a basic designing problem somewhere…
People will ask themselves why they cannot simply turn the wheel and slow down like with other cars ?
Interesting analogy. I can see your point.
The constructor has to solve his mechanical problems and not show how it is complicated to construct a car, it is not the conductor’s problem.
Tricky still for Frits though. I certainly think he has done a great job so far. He will surely improve things further as he has done in the past. I guess we can only do our part by bringing these issues and suggestions up and let him take it from there. 8)
a “total recall” of the opened plugins and windows etc…
Something like one of these features…maybe? 🙂 😛
One of the problems is that Podium doesn’t know the difference between an “audio track”, an “automation track” or a “MIDI track”.
Which funnily enough allows for extreme flexibility and power when managing and using different track types. Strange in a way but it’s one of Podiums unique selling points.
I appreciate a lot not to have to create specific tracks like in some other DAWs, but perhaps if Podium will associate an invisible “code” to each lane according of what kind of data it has on or what kind of mapping (it would be easy for automation parameters lanes), it will avoid such confusions when copying events between tracks ?
For instance, if I put an audio file on a track, an audio “marker” is automatically associate to it. Then an audio event will have to “jump” to the next “audio maked lane” when pasted ? It would perhaps prevent it to be pasted into an “automation marked lane”.
I have to say your idea in theory at least (only Frits will know how practical your suggestion is) really does sound very clever. On paper it seems very workable. But only Frits really knows as the developer (I guess) if it will work. 😐