Cubase SX 3.01 b514 update released

[Sascha Franck]

OK, first off, a HUGE "Thank You, sir!" to Mr. Rozzer who explained the generic remote thing to me (in the KVR chat).

Anyways, it's indeed that I can now route any CC to any mixer or VSTi parameter (I wonder as this should've been somewhat possible before, just that nobody told me when I asked...).
Which, in short, is just freaking kickass! Now I can finally use plain MIDI data (CCs that is) to automate all sorts of VST(i) or audio channel parameters. I like that 10000x better than trackbased automation for creative automation use!

The downside however is that these settings aren't saved with the song.
OK I (I shall better say "we" because Rozzer was the one who agreed...) can see the general idea behind it, being that you're using whatever remote control unit to mix things (all that motorized fader blah blah stuff...), set it up once to suit your needs and then keep it like that for all the times.
For such purposes it's all OK in case things aren't saved with a song.
Further, in case you write your data onto automation tracks (rather than úsing MIDI record) it's all OK as well. This will be played back properly as well, regardless of your generic remote settings.

BUT (!): In case you'd like to use automation, say, "creatively", such as in dragging CC parts around, stretching them (just try with an automated filter cutoff and you'll know what I mean) and whatever, the CC-to-parameter settings need to be recalled with the song.
Now, ok, you CAN just save the XML file along with the song in your song folder (via the device setup's "export" function), so it's just a minor workaround which is required, but still, after getting used pretty much to CTRL-S-ing, I will now have to get used to save that XML file as well (and load it with each and every project to have it play back properly).
There should at least be an option to "burn" these settings into the songfile, should one ever decide a generic remote setting wouldn't do the job for a certain project (which would be like all the times for me).

However, I am VERY happy about this functionality and it also seems to work pretty fine!
And again: HUGE thanks to Rozzer, who explained it way faster than the manual would be able to!

Cheers,
Sascha

[Sascha Franck]

OK. What I described before doesn't work, not at all.
A) It's buggy as hell. My assignments were all lost after only fooling around with it for a bit. Out of the blue. Reloading the XML file didn't help. Only reloading the song did. Shit!
B) In case you reroute CC data to whatever data (such as, say, a delay send), recorded events of the same CC won't be rerouted. It seems that all those rerouted events completely bypass the sequencer - no, actually it's vice versa, sequenced events bypass the Device Setup's rerouting. So, only realtime input is taken into advance, recorded data isn't.
You need to write automation data or leave it alone entirely.

I was sooo happy about this at first, now it's just useless for me again.
This kinda sucks.
Seriously, that would've been quite something making me help my partial transition from Logic. Now it won't.

[stag]

It´s already possible on SX2 to record and control VSTi and some VSTfx ,like vocoders from a midi controller.
Now it seems that VSTfx paraneters are contolled as well on SX3.

I told you that before Sascha.
with all due respect you´d better make your own DAW
or get someone to do it for you , i guess mere users like myself have to input something to get the job done and take advantage of our tools.

that´s a good upgrade and RoomWorks has good qualities.
Sound wise is more akin to RM2 albeit a lot less fidly. IMO has a lot more transparency than Ambience.
A rather good mastering reverb RoomWorks it is.

Still SX doesn´t clean and cook YET.

[kritikon]

I'm still not sure what you mean when you say you can't stretch automation parameters, Sascha. When I record or write in automation stuff, I can stretch it or shrink it as much as I want. You simply highlight the blue dots into red ones, then drag the red dot out to where you want, and the line or parabola or whatever stretches out or compresses in accordingly. So if I have say a delay feedback or delay cutoff that starts at zero at bar 16 and increases to maximum at bar 24 - if I want to extend that out twice as long, all I do is grab the automation point at bar 24 and drag it to bar32. The ramp or curve will then renew to new 16 bar length. Surely that is timestretching the automation?
I regularly do that with FX parameters - I use an awful lot of FX automation in my music, and if I want to later on insert extra parts and consequently time stretch the automation - that's how I do it - simply drag and stretch.

You can set the snap so that you drop the automation points exactly on bars, or even turn it off or have it set to 1/64ths or whatever. And you can group highlight a whole set of automation points too, to drag all in one go. I can stretch out delay cutoff, resonance, feedback, panning all with one mouse drag.

Have I got the wrong end of the stick somewhere about what you mean?

[Sascha Franck]

You can set the snap so that you drop the automation points exactly on bars, or even turn it off or have it set to 1/64ths or whatever. And you can group highlight a whole set of automation points too, to drag all in one go. I can stretch out delay cutoff, resonance, feedback, panning all with one mouse drag.

Have I got the wrong end of the stick somewhere about what you mean?

No, it's more or less what I mean - but, if you have a curve of multiple automation nodes, you can't stretch it so the multiple nodes will keep their relation to each other following the stretching amount.
Example: First node at bar 1, beat one, second node at bar 2, beat one, third node at bar 3, beat one.
Now, let's say I wanted this passage to be timestretched to 4 instead of 2 bars.
For a "normal" MIDI sequence I would just select the time stretch tool, grab the right corner and drag it to bar 5, beat one. Everything inside the sequence would follow the amount of stretching relatively.
Automation data won't do so.
Yeah, with only these 3 nodes it'd be easy. I would just manually adjust the required 2 ones. But that's impossible in case you have a whole lot more of automation nodes in some rather complexed curve that you might have entered by using a HW controller.

Further, my main gripes with automation (and as saidn before, the very same is true for Logic's automation as well) are the ways to select parts.
I need to zoom around a lot to do this properly, while grabbing a "CC driven" part is the easiest thing in the world (it's just like MIDI parts).
And finally, SX doesn't move automation automatically with other parts, which is a pain too.
When dealing with additional CC parts for, say, a synth, I can just easily select them along with the synth part (or I might put all of them on a group track, depending on the situation).

Seriously, I just hate all that node and trackbases based automation stuff in any sequencer, apart from using it occasionally while mixing.
In Logic I do at least have some sort of workaround for some automated data, say, a fader send or a cutoff movement - I can just record them as plain MIDI data. Not so with SX.
And I was having high hopes generic remote would cure some of those issues - but as the generic remote only reacts to incoming CC signals, rather than to recorded CC signals as well, I guess I can just forget about it again.

[HHaynes]

No, it's more or less what I mean - but

Sascha - if you ever wrote a sequencer - you'd only have one customer - you.

[Sascha Franck]

Sascha - if you ever wrote a sequencer - you'd only have one customer - you.

I wouldn't happen to know if you were joking or not, but rest assured that everything I am suggesting would be QUITE useable for a lot of people, and also, rest assured again that my requests and input have been more or less welcomed a lot in various beta tests I've been involved in (and, not to pad myself on the back too much, quite some things have actually been implemented as well in some products you might be using or might've used allready).

[griels]

No, it's more or less what I mean - but

Sascha - if you ever wrote a sequencer - you'd only have one customer - you.

Hey, I'd buy it... This thing would ROCK

Seriously, I would like to see the stretching SF is talking about here... It is actually something that bothers me too.

[ericj23]

it does sound good - its never a thing ive needed - but god it would be useful if i did

[Sascha Franck]

OK, I may just rephrase my request, so it might become clear that I'm not exactly asking for the current generic control to be completely re-written or f**ked up in various ways or whatever.

First, what I would like to see for a whole number of reasons (which I allready explained I think - whether someone else needs this is, well, up to him/her, I'm sure it'd be a benefit for many people):

A way to treat automated data (of whatever sorts, basically plugin parameter and channel settings control) like your "average" MIDI parts.
Even if I allready did so, I will try to describe the possible benefits again:
- Parts on many occasions are easier to tweak (move/copy) than the (only-)node-based track automation. Especially when dealing with zoomed-out project sizes.
- Parts are easier to mute temporarily (so you can A/B various versions etc.).
- Parts can be timestretched incredibly easily.
- You don't need to deal with automation group tracks and selecting the correct parameters first because you simply recorded things "part style" from the very first moment - so they're just there.
- Parts can be merged into each other, which sometimes might make sense, should you ever wish to edit, say, MIDI notes along with automation in key edit (which would defenitely make sense in case you automated, say, a filter cutoff). Alternatively you could as well just switch to multiple part view in key edit.

Again, you (and many other people perhaps) may not need all of these, but I don't think it's some completely esoteric wish either.
I also can assure you that quite some people I worked with during the last few years just loved some of the tweakings I did this way (in Logic that is).

OK, now, I didn't mean to exactly jump on the way generic control is working, but I thought it'd be a good starting point to get there.
Things could however be implemented in various ways.
Top of my head I can think of these three:

1) Using generic control. But, unlike it is working right now, it should be placeable behind the sequencer optionally, rather than only responding to MIDI input. If you record CCs, they won't be rerouted to the generic control mappings you've done allready.
2) Using a "generic control style" functionality for the input transformers. That would include both the MIDI message input part of it (including MIDI learn) and the output line (easy selection of whatever parameter).
3) Using a "per item" MIDI learn mode. This would include just about anything you could do on either your mixer or plugins - regardless whether the plugin in question allready is offering such a functionality by its CC implementation.

OK, before anybody is jumping on me again, I can clearly see some flaw coming along with any of those 3 approaches:
Double assignment of CCs to parameters, especially when it comes to controlling plugins offering internal CC routings. But this could allready happen with the current generic control implementation as well. And it's never been getting too much in my way when working in Logic either.
So I'd consider this being a matter of organisation.
In an ideal world, Cubase would even ask you whether you'd like to use the CC assignment indeed, which could even happen on two occasions:
"Stop! CC is allready used to control parameter XYZ! Use anyways? Yes/No"
"Stop! Parameter is allready controlled by CC XYZ! Use anyways? Yes/No/Reassign"

However, as for the current state, it'd probably be the easiest thing to slightly change the current generic control implementation (in addition, I'm not talking about leaving out any of the options we allready have!), as described in 1). This might however open up for a lot of possibilities regarding conflicts in case you would use generic control as it is in addition.
The most ideal solution would perhaps be 3), complete MIDI learn/assign is a wish I'd have for ANY sequencer out there (I think FL does so allready, not 100% sure how well it is implemented). But I would guess this would require quite some rewriting, so it's unlikely to happen any day soon.
That's leaving us with 2) - which would perhaps be the most suitable solution anyways. All that needed to be done is to give you direct access to mixer and plugin parameters in the "action" portion of it - which - as an allready working functionality - could be stolen/adapted from the generic remote control window.

OK, these days most plugin companies allready deliver proper CC implementation of their plugins, but in may of those it's "burned in" rather than freely assignable. And you allways need to look up some lists as well (which is so, shall we say, early 90-ish... dealing with endless MIDI implementation lists). In addition, there's still quite some plugins not offering any CC implementation on their own.
Further, even if your plugin's MIDI implementation is perfect (such as in having full MIDI learn), this still doesn't let you deal with audio channel parameters, such as, say, delay sends.
Just imagine you'd have a nice patch and would assign one controller to both cutoff and delay send. So, whenever the cutoff would be raised, the signal would be delayed as well. Or distorted. Or mangled in whatever way.
And it would be ALL recordable into ONE single step into ONE single part, rather than into a divided bunch of MIDI parts for notes and automation parts for channel controls - let alone that you wouldn't only have to press record but also activate automation write as well as it is right now.
And then, just imagine you could simply stretch all the recorded part in ONCE simple dragging move - all your cutoff movements, all your delay/distortion/mangling tweakments would be stretched simultaneously as well! This last part can't even be done using whatever workarounds right now.

So, as you may see, the creative possibilities of such an implementation are endless.
And, not to forget, the technical requirements are allready there. There's CC-rerouting, there's input transformers too - now all that needs to be done is to combine the two.

Phew, lengthy post - but I hope it DOES now make SOME sense for SOME people. I can see quite some benefits in this.

[ericj23]

I like the current generic remote - altho it should have a by song save

as for the automation how about having a automation to part option - ie you select some automation - all on a track or whatever and it turns it into an appropriate sized peice of midi data that can then be altered/moved as required - you then have part to automation and convert it back - OK it might get fiddely when transferring from one channel to another as you would need some kind of assign cc to parameter control -

that should be easy to implement as the generic remote cubase can clealry link cc's to any vst parameter - it just has to remember them as any processing is done on the midi part

but in truth total midi learn of any parameter is what is needed with all the assignments saved with the song - you can then input automation data as ccs and copy it about

now how to convince steiny of this wisdom ?

generic remote control of the mixer panels is an absolute essential - as well as them being able to read syssex or something so they can contain any instrument presets (cos i am not putting them all in manually)

[Sascha Franck]

as for the automation how about having a automation to part option - ie you select some automation - all on a track or whatever and it turns it into an appropriate sized peice of midi data that can then be altered/moved as required [...]

This is allready possible in Logic.
Yes, it would make sense for sure - but from using it allready I can just tell you that things do indeed get "fiddly" (as you admitted yourself too).

but in truth total midi learn of any parameter is what is needed with all the assignments saved with the song - you can then input automation data as ccs and copy it about

Yeah well - as described, input transformers might just do a great job for this.
With such an option (along with "copy to/from automation" you mentioned) one could just work in whatever way one would like to.
Personally, I would most likely never copy to or from automation but just stick with plain CCs, but other people might prefer automation data.

now how to convince steiny of this wisdom ?

Yes - how?

generic remote control of the mixer panels is an absolute essential - as well as them being able to read syssex or something so they can contain any instrument presets (cos i am not putting them all in manually)

Personally, while I find generic remote to be a way better concept than, say, Logics implementation of things, I just don't need it at all.
I mousemix almost exclusively and only use outboard controls for certain creative useage which I've described in my previous post.
But again, each to his own, as said, generic control per se looks like a really nice thing in case you need it.

[cold c]

And finally, SX doesn't move automation automatically with other parts, which is a pain too.

MIDI automation does move automatically with the MIDI part, and audio event automation automatically moves with the audio event. If you mean VSTi/fx automation moving automatically with a MIDI part, it's simple enough to just select the part and the VST automation and just move them.

In Logic I do at least have some sort of workaround for some automated data, say, a fader send or a cutoff movement - I can just record them as plain MIDI data. Not so with SX.

You can't record standard CC data with SX? Why not? If you mean you can't automate internal mixer parameters with already recorded MIDI data then that's true, but most would use proper automation for that task anyway.

And I was having high hopes generic remote would cure some of those issues - but as the generic remote only reacts to incoming CC signals, rather than to recorded CC signals as well, I guess I can just forget about it again.

If for some reason you want the generic remote to react to recorded MIDI then did you try one of the virtual MIDI port utilities?

Anyway, I do think that Generic Remote usability could be improved similar to how you described,

1) Using generic control. But, unlike it is working right now, it should be placeable behind the sequencer optionally, rather than only responding to MIDI input. If you record CCs, they won't be rerouted to the generic control mappings you've done allready.

I don't understand this. Please explain the behaviour you do and don't want separately.

3) Using a "per item" MIDI learn mode. This would include just about anything you could do on either your mixer or plugins - regardless whether the plugin in question allready is offering such a functionality by its CC implementation.

...

In an ideal world, Cubase would even ask you whether you'd like to use the CC assignment indeed, which could even happen on two occasions:

...

This would be useful, like most other MIDI learn features, I think it could fit in with the existing generic remote, I don't think the generic remote would require "rewriting" as you say, just a lot of implementation. If you want the control to be assignable to more than one parameter I don't think that would be a huge rewrite either.

For the warning messages instead of saying the "CC" it could say, "Fader 1 is already assigned to parameter Blah, assign anyway? Yes, No, Yes and uassign from Blah" and also "Blah is already controlled by Fader 2, assign anyway? Yes, No, Yes and unbind from Fader 2".

I don't entirely understand the preference of CC data to the automation given the bit depth issue (and I prefer adjusting automation to adjusting CC data), and I think most improvements could be made to the existing system (which is far from perfect) like dynamically reassigning GR controls to any parameters (with a right-click or similar) as you mentioned, or right clicking on an automation lane and selecting "GR learn" or similar, or simply allowing the generic remote window to be open with the project not as a modal dialog as it is now but something that is as easy to access as a mixer window, however IMO that would be second choice to the right-clicking on any mixer control to reassign a GR control.

So basically I think the current GR needs to be improved instead of rewriting it or changing its model, all the useful improvements could be made under the current "paradigm".

I mousemix almost exclusively and only use outboard controls for certain creative useage which I've described in my previous post.
But again, each to his own, as said, generic control per se looks like a really nice thing in case you need it.

Yes and it's not just for "mixing" but supposed to be for every function in Cubase, you can control transport functions, macros, MIDI functions, open windows etc. etc.

[Sascha Franck]

MIDI automation does move automatically with the MIDI part, and audio event automation automatically moves with the audio event. If you mean VSTi/fx automation moving automatically with a MIDI part, it's simple enough to just select the part and the VST automation and just move them.

IMVHO it's not easy enough, this should optionally be an automated process.

You can't record standard CC data with SX? Why not?

Of course I can...

If you mean you can't automate internal mixer parameters with already recorded MIDI data then that's true, but most would use proper automation for that task anyway.

As described rather carefully in my lengthy post there's several reasons why I just don't want this.
I allready gave an example, here it is again:
Play a synth part while tweaking channel parameters, such as an FX send. For more than obvious reasons (at least obvious for me) I would want to treat this part as a "single item" rather than having to look which automation data I had to fetch up in order to, say, copy it. Let alone that timestretching isn't possible.

If for some reason you want the generic remote to react to recorded MIDI then did you try one of the virtual MIDI port utilities?

Not yet. Allready thought about it - seems to be a rather complicated approach regarding the relatively simple things I would like to do.

Anyway, I do think that Generic Remote usability could be improved similar to how you described,

Well, as said, I don't even think that it necessarily had to be the GC remote stuff.
What I would like to see would also be possible if certain GC functionality would be implemented into the input traqnsformer section.
Or by a proper MIDI learn functionality for whatever parameters I'd like to assign.

I don't understand this. Please explain the behaviour you do and don't want separately.

See, whenever I assign a MIDI CC to whatever parameter, then record the CC (rather than using automation write) it won't adress the parameter assigned in the GC menu when being played back.
This is because the GC is POST input but PRE sequencer. There's good reasons for that as well - because recorded stuff wouldn't conflict with, say, another GC script that you may use on another computer, with another controller, etc.

In short: GC is designed to work with track automation. It's not designed to "work" with CCs, those are only used to trigger certain parameters, which will then be used to write track automation.
Fine - I allready said so.
And believe me, I don't want anything to be changed there.

Still, I DO want to record MIDI CC data to control certain channel and plugin paramters - you may or may not agree with me that this is offering quite some of the allready described advances, you may or may not need them either - but I do think many people would benefit from what I am suggesting.

Finally, after thinking about it again, I think the most viable way of implementing things into SX as it is right now (instead of completely rewriting enormous portions of the code to add, say, MIDI learn straight on the desired "items") would be to add the MIDI assign/learn functionality of the GC (which is actually really great) to the input transformers.
That way one could use GC for, say, "general assignments" on a per computer/controller base and use input transformers for a per project base.
In an ideal world one would be able to copy assignments (or portions of them) between the two.

I allready said so: This would indeed open up for some potential conflicts, as parameters would be adressable twice. Let's say you just have CC 19 assigned to tweak your audio channel's 8 level and now you would assign it to tweak whatever synth's cutoff as well - you may not want that! But in case it was really well implemented, SX would just ask you whether you're sure about your decision.

About your sentiments regarding bit depth of CC resolution: You're somewhat right with that.
But then, I allready mentioned it, I have been using a similar "handmade" system in Logic for a while now (I tell you, assigning things there is NO FUN at all, massive workarounds and tweakings of socalled transformers are required to get you there), I can assure you that CC resolution rarely got in my way.
For things such as controlling FX sends it's a minor issue anyways, for the occasional cutoff tweak it's usually OK as most modern synths have smoothed filters.
It IS critical on automating bypass states, but for that I would indeed use sample accurate track automation instead (I almost never use that though).
It's critical for certain other parameters as well (i.e. old synths that don't have smoothed parameters), so you may experience some stepping or parameter jumps, but personally I haven't experienced much problems with most synths lately.
Also, there should allways be an option to transfer data to the sample accurate and fine-resoluted (word?) track automation, should you ever need to do so.

[Sicklecell666]

Sascha, quit bicthing about Cubarse with the silly zealots & get back to helping us beta test that VST dumper