Cubase SX 3.01 b514 update released

[Sascha Franck]

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

Hehe - no worries, just about to test the latest build.

[stag]

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

may i rephrase:
Quit zealoting with silly bitches and help us to find our asses with both hands,

[Sicklecell666]

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

may i rephrase:
Quit zealoting with both hands and help us to find silly bitches with our asses,

demn, man..That's profound..

[cold c]

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

Feature request.

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.

:loop1

The two reasons you want generic remote to react to already recorded MIDI data are:
1) Automatically moving the VSTi/fx automation with the part (see above feature request)
2) So you can time stretch that MIDI (because standard automation doesn't timestretch)

?

You want them to implement a feature (GR responding to recorded MIDI) so your intended workaround for the two other missing features (timestretching automation and moving VSTi/fx automation automatically with part) will work? Why not just ask for the missing features in the first place so you don't have to use a workaround??

Those issues/features should really be addressed directly, not with some workaround soup.

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

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.

goto loop1

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.

From your post I have identified these main feature requests:

1) Option for automatically moving the VSTi/fx automation with the part
2) Time stretching automation
3) Easier generic remote assignments (right-click on any mixer parameter or any automation track etc.)
4) Saving (some or all) generic remote assignments with the song, or separately from the main GR assignments

The other feature requests were workarounds that wouldn't be required if the above functionality was there.

Your point about the MIDI transformer would only be required if you still wanted to record CC data instead of automation data after the above features had been implemented, unless you only mean something similar to the MIDI transformer but with automation in/out (which again would not be necessary if the GR was well implemented in the first place).


And now to some workarounds for Sascha -

For converting any SX3 automation to and from MIDI CC data-

Tools required: rgc z3ta+ or similar (demo version might work, it may also work with other plugins)

CC to automation

1) Copy your CC data to a track by itself
2) Open z3ta+ VSTi and route your MIDI track with the CC data to z3ta+
3) Right click on a slider (say cutoff for example) and choose MIDI learn
4) Enable "W" on z3ta+ to write automation
5) Playback the track
6) z3ta+ will output the CC data as automation to SX
7) copy that automation from the z3ta+ cutoff track to any automation track in SX

automation to CC

1) Create a new MIDI track
2) Copy the SX automation from anywhere you want using the range selection to copy it.
3) Expand the MIDI track automation lane and choose the CC you want to convert the automation to.
4) Paste the automation in the MIDI automation lane
5) Move the left/right locators around the automation you want to convert
6) Solo the MIDI track, ensure the MIDI track is selected, right click >> MIDI >> merge MIDI in loop
7) Cubarse renders the MIDI automation as standard CC data.

Hope that helps.

[ericj23]

the only thing is if the input/transformer to vst automation was possible all the 4 features you suggest would not be needed

although the easy remote setting and with song saving would be great

[Sascha Franck]

the only thing is if the input/transformer to vst automation was possible all the 4 features you suggest would not be needed
{/quote]

Yes, that's what I was saying. One could just work in whatever way one would like (and it'd only become better if one could move data around more or less freely between automation and CC data).

although the easy remote setting and with song saving would be great

Yeah - but perhaps there'd be conflicts with people using remote control "traditionally" - so it'd better be an extra feature set.

To cold c: Yes, those 4 are basically the things I would like to see.
In addition (and that was where I started originally in another thread), take that as #5, I would like to "handle" automation as parts rather than a bunch of continuous lines connecting nodes.

As far as your workaround goes, well - that's not exactly bringing me close to #6:
Treating a VSTi PLUS channel effect tweakments as ONE entire thing.

I will post a sample snipplet made in Logic, describing what I can do there (admittedly using VERY weird workarounds) later on.

[ahja]

Sascha.. Why don't you just use Logic then if you have so many problems with Cubase?

[Sascha Franck]

Sascha.. Why don't you just use Logic then if you have so many problems with Cubase?

I think I allready told you (and others) numerous times allready:
- I have to use it for a wide variety of reasons (one of them being that it's part of my job).
- I actually do believe that PCs are the platform of the future.
- I want to use an up to date sequencer on the platform of tbe future.

Further, I allready said so as well, doing this in Logic requires quite some workarounds as well. And, in addition, what I'd call the "background technical specs" aren't given either in Logic. In SX they are (there's CC learn, there's CC reroute and there's easily available input transformers too - none of them exist in Logic without MASSIVE thinking and work).
And obviously, if there's one program for Windows that might one day fulfill my wishes, it won't be Logic.

You still seem to get me wrong. I DON'T want SX to do anything esoteric, I also don't want it to be my new Logic and I also don't blame everything - if you followed my posts thoroughly you will notice that I actually called the GC thing very well laid out.
What I DO want is some things that have got nothing to do with Logic at all. They'd be wishes of mine even if I'd never used Logic before - I am 100% sure about this because they've been long time Logic wishes as well.
I am only using Logic comparisons because I am very familiar with it. And that's about it.
And I am also familiar with certain expectations regarding workflow. Logic doesn't exactly fulfill those in many areas, and Emapple didn't even seem to implement them in any versions newer than 5.5.1 either.
SX doesn't fulfill my expectations regarding workflow either, but as I said, the technical background IS allready there.
Take hitpoints to MIDI notes (we allready discussed that): The functionality I'd like to see is allready there in background. You just can't access it without more or less massive workarounds (OK, they are not THAT massive, still, they are workarounds).
Why not make it easy for the user and offer a simple "extract hitpoints to MIDI notes onto selected track"?

This CC issue is the same. As said, all required technical stuff IS there allready. We just can't access it properly.