Can you show a video?

If you turn something on, like a Leslie, it will be on until it receives an 'off' message.

S1 records what you send it.

You want S1 to start adding midi events on its own? I don't.

Thanks.
I don't think it shows any better in a video, but will download that gif animator you have links to somewhere.

Try to give more examples

Another example - having drawbar fully out - I am on level 8(saw in midi monitor before recording).
Start record playing notes, let' s say 4 notes
Then I start moving 16' drawbar in slowly, first to 7, 6, 5 etc
If I then stop record and play back or look in editor - 16' drawbar get value 7 at start of clip and first note

you have 16' draw bar having a node at value 7, which is the first recorded
If it would play back only when touched and where node is - would be fine.
But it doesn't - it extrapolate to clip start with value 7 of clip.

For some controllers this is major malfunction - mostly on on/off kind of jumps in value.
Another that comes to mind are leslie on/off that is disaster.

For leslie on/off as one
- start playing notes, not touching leslie button
- then press leslie button while playing with leslie on
- turn off leslie button and play some more notes
- stop record

- when playing this back - the first on-value of leslie will be on from start of clip.
Unless there is a first node - it should not bother playing it back - but it does.

Or is there some setting to use to handle a controller not as continuous from start of clip - with the first nodes value?

Other examples - you play a synth - and while playing you turn knobs on panel to get those recorded. Like Attack knob on filter or amp.
It will be the same mockup not playing back as recorded, kind of.

What you usually do - select a preset so it sounds as it should from start
- start recording and turning knobs
This will not reproduce what you had as recorded as played back later.

EDIT: changed some bad examples to better ones

Tacman7 wroteIf you turn something on, like a Leslie, it will be on until it receives an 'off' message.

S1 records what you send it.

That is not what I ask - StudioOne to be mindreader....

If it actually sent the node where placed - but it doesn't - it sends node at beginning of clip - since it extend that as an initial value kind of.

- ok, that is the first value of a node
- let's send this right as clip starts
- not where node is

StudioOne does not treat controllers as data where it's put - for first value - it thinks as automation and first value is initital value - which it isn't.

I obviously take responsibilty to send program change to init an instrument before playing back, so start is consistent.
Then it comes to first node of a controller change - then it should send that controller - not as clip started.

But as StudioOne treat it - it's unusable.

Some controller that you might have at zero - like mod wheel when starting - and as recorded and played back you start at '1' instead - it's usually such a small change that you don't notice that first value of wheel is '1' not '0'.

But for other types, especially jump on/off stuff - it's a mockup.

Not sure if I can explain better.....

Tacman7 wroteIf you turn something on, like a Leslie, it will be on until it receives an 'off' message.

Not gonna try to decode all the steps but it sounds like a misunderstanding of the Part Automation system. Because that statement is not totally accurate.

Please post a video or if you have to make a GIF you can attach it here.

All I can say is that what you're describing (adjusting virtual instrument settings and having them be stored as Part Automation in a midi part) works perfectly fine when I do it. So without seeing some extra step you're going through or missing or whatever I'm not sure why you're getting a different result.

Are these Instrument Tracks routed to a virtual instrument or playing an external hardware instrument?

Thanks again for hanging in there.
No it's to an external Hammond XK3c, but it's a general midi thingy as far as I can tell.

And I made one wrong assumption - CC64 is treated as on/off - and when receiving first value being above 64 it assume correctly initial value should be opposite, and therefor zero.

But testing with CC1 and others, as well as NPRN stuff it will take first node as recorded as also being initial value - and which wrongly is sent at beginning clip.

Have midi monitor up and you can see as playback cursor enter clip - first node value CC01=1 is sent right there - not waiting until node at 2.3.3.

Check out pic.


EDIT. Added a bit in comment on monitor as a good way to reproduce

No I was talking about midi cc events.

1- are you sure that first value is 1? you can check by hovering over the node

2- if it is 1 (and not 0 as you claim it should be), How are you inputting this data?

When I write part automation with the mouse using the controls on the plugins GUI or from my Komplete Kontrol S61mk2 it correctly registers the beginning value (pre-move). A node for "0" is created, so I think something else is probably the issue.

I had seen this issue in this way:
Insert a program change node along the timeline in the editor (it's the first one), and set its value - the value is extended to the start of the track.
Had to crop this gif severely to post it, but ...click on it to play animation.


(Understand, I want a transition to be inserted there, and my original setting (1) to be unchanged)

patrickbushaw wroteI had seen this issue in this way:
Insert a program change node along the timeline in the editor (it's the first one), and set its value - the value is extended to the start of the track.
Had to crop this gif severely to post it, but ...click on it to play animation.

S1_AutoNodeExt2.gif

(Understand, I want a transition to be inserted there, and my original setting (1) to be unchanged)

You need to create two nodes. Drag the second one above the first so it snaps to a right angle instant transition. Then right click the top node, type in your desired Program Change # and hit enter.

robertgray3 wrote1- are you sure that first value is 1? you can check by hovering over the node

2- if it is 1 (and not 0 as you claim it should be), How are you inputting this data?

When I write part automation with the mouse using the controls on the plugins GUI or from my Komplete Kontrol S61mk2 it correctly registers the beginning value (pre-move). A node for "0" is created, so I think something else is probably the issue.

Thanks, yes, I looked in midi monitor - it send the same value of first node in the beginning if clip.

StudioOne extrapolate the first value treating as initial value as well. I write automation only for audio stuff - never midi, it is as recorded live.

patrickbushaw wroteI had seen this issue in this way:
Insert a program change node along the timeline in the editor (it's the first one), and set its value - the value is extended to the start of the track.
Had to crop this gif severely to post it, but ...click on it to play animation.

(Understand, I want a transition to be inserted there, and my original setting (1) to be unchanged)

Thanks. As a workaround this is what you have to do - on every controller.

Not sure I understand how a program change makes a difference, other than initializing instrument to something as a preset - which is what you do at beginning of track.

Every controller you touch will have to be reset to it's value in that preset - so sound does not change until the node as recorded is to be played - the way studioone works now,

But studioone should not handle midi cc like this, or as cubase allow to set if to treat certain controllers as data and left alone or as continuous automation.


But in real life it's unusable as it is now - thinking of going through a live performance turning knobs - and expecting this to play back sounding the same.

To make this play back as it were performed you have to go into editor and edit maybe 10 different midi cc like this - looking at the preset in a synth you used, what was initial value in that preset - on every knob.

Because it will need to send whatever initial value in synth is as starting to tweak in realtime - and now it assumes it is the first controller it records, which it isn't.

It's not doable - it's a showstopper.

I'm going back to Sonar now - and stay there unless fixed this spring - it handle this perfectly. Does not invent stuff that I did not do or intend.

There are a couple of things not up to par in studioone working with midi cc. All effort is on editing notes but with controller it is seriously lacking. I can live with those - but this thingy it's nothing I can live with.

It's not unusable. What you're asking for is possible, have you thought about asking one of those Studio One coaching things for a session? Like Home Studio Trainer etc.

Because you haven't posted a video it's really hard to understand where you're going wrong and what tool to point you to. Have you tried disabling the setting for "automatically generate an automation envelope for every touched parameter" in the automation settings?

robertgray3 wroteIt's not unusable. What you're asking for is possible, have you thought about asking one of those Studio One coaching things for a session? Like Home Studio Trainer etc.

Because you haven't posted a video it's really hard to understand where you're going wrong and what tool to point you to. Have you tried disabling the setting for "automatically generate an automation envelope for every touched parameter" in the automation settings?

Thanks.

That to create automation on touch is disabled since long. I never do that manually - I record midi live.

I really don't see how a video would show anything. It's not a dynamic thing - it's there once recorded.

Just empty midi track armed to record
- start record transport with mod wheel at zero as you start
- play some notes where no mod wheel is to be active
- then after some bars start moving wheel and play some more notes
- stop recording

That's it - no video needed. You see result in my screen shot.

Looking in midi monitor as soon as tranport for playback enter the clip - this cc01=1 is sent. The node is at 2.3.3 - but sent right as clip start, before even first note is played.

This recorded clip above will send cc01 as value 1 from start of clip - but as I recorded the first part and where first node of cc01 is - it should not be any cc01 sent until the actuall node.

In real life this tiny value cc01=1 is not noticed that much - so it's an example easy to reproduce. And why I did not notice before.

No midi cc should be sent until node. Sonar does not do that, it just send data where it's recorded - no tricks.

And with midi cc in general in studioone this is unusable. One is special treatment in studioone - cc64, also named on/off in name - and that works. Maybe there is some other cc also treated this way.

But seems all other cc is treated like continuous automation and studioone invent an initial value for start of clip - and it should not do that. Just play where node is.

And as I discovered Hammond sending leslie on/off over NRPN - leslie is turned on at beginning of clip.

So found workaround, noticing this, and recorded leslie on and then off first before playing any notes.

But route I am planning for - doing all kinds of live tweaking on knobs over time. StudioOne inhibit me doing this. You have to go through and edit every controller to have toucned to have correct value before touched at start of clip.

If StudioOne only sent anything midi cc where nodes are entered - all would be fine. It's translating it to automation lane that create a problem.

@Nip, I understand where you are coming from. In Cubase there's also the traditional MIDI system, so there's only data send where there was data recorded. Next to that Cubase has some settings to control the way CC data is chased. I'm really used to that way of working.

Still I'm not sure what method is better for various reasons.
Let's assume the part at 0003.01.01.00 in the image below is the first part in the song.
Can you explain what values you would expect between 0003.01.01.00 and 0003.03.01.00 (unknown value) and 0005.01.01.00 and 0005.03.01.00 (what value should be here?)?

niles wrote@Nip, I understand where you are coming from. In Cubase there's also the traditional MIDI system, so there's only data send where there was data recorded. Next to that Cubase has some settings to control the way CC data is chased. I'm really used to that way of working.

Still I'm not sure what method is better for various reasons.
Let's assume the part at 0003.01.01.00 in the image below is the first part in the song.
Can you explain what values you would expect between 0003.01.01.00 and 0003.03.01.00 (unknown value) and 0005.01.01.00 and 0005.03.01.00 (what value should be here?)?

Thanks, as often niles to the rescue.

Cubase also has this virgin territories for normal automation - and a matter of taste how you want it. Looks pretty much as you show. Option for you to use as it fits how you work.

I don't mind connecting the dots, kind of, just don't start guessing wrong and sending what was not recorded events.

Show as continuous line - no problem, even from start of clip. It's a good guide for eye to quickly follow what happends in a CC-lane.
Just don't treat that start of clip as the actuall initial value to send - this is what causes the issue. Send when event is there - end of story.

As it is now, you cannot even place an init clip for instrument in front, like I usually do, to always initialize instrument as it should be when playing back. As soon as it comes to another clip - midi cc is sent as initial values and destroys what is initialized before it is to be used - as recorded.

I ran in Sonar Artist 2015 this morning, and all works fine there - nothing sent that is not recorded. No worries.

Editing features on midi is actually more extended - simple option to include controllers i range as you select notes.

Think about download Cakewalk by Bandlab to see how it looks today.

So how to best report this - it does not feel Presonus Answers is ever read?

Nip wroteShow as continuous line - no problem, even from start of clip. It's a good guide for eye to quickly follow what happends in a CC-lane.

But a line would only make sense if it represents the actual value. If the end value in the previous part was 127 (0003.04.01.00 in my image) and no value in the next part (0005.01.01.00) the line should then be at 127.

But when there is another part with a different end value added in between or when the end value in the previous part is altered, the line should reflect that too. And there is becomes tricky both musically and visually. Because an alteration made in the current part will also affect the next part unless you manually add an initial 'save' node.

Nip wroteJust don't treat that start of clip as the actuall initial value to send - this is what causes the issue. Send when event is there - end of story.

Yes that's clear. But there are scenarios where the initial value is helpful. For instance to bring back parameters to their initial state when the song starts. Or if you want part automation to stay untouched no matter what's happening in front of it.

Nip wroteAs it is now, you cannot even place an init clip for instrument in front, like I usually do, to always initialize instrument as it should be when playing back. As soon as it comes to another clip - midi cc is sent as initial values and destroys what is initialized before it is to be used - as recorded.

Both methods have pros and cons. There's a reason other DAW's have an option for this.

niles wroteYes that's clear. But there are scenarios where the initial value is helpful. For instance to bring back parameters to their initial state when the song starts. Or if you want part automation to stay untouched no matter what's happening in front of it.

For those remotely useful features you f-k up so no live recording of midi recording is doable?

I think they got stuck on making it the same as audio automation - and didn't quite think it through(IMO then).

There are a bunch of options in both Sonar and Reaper.
- zero controllers on stop
- chase controllers on start
and various things like that.

StudioOne has options for midi notes include things like, create note off if clip ends and note is on etc. And load of macros etc.
But for midi controllers I find it really lacking big.

I had a struggle getting an unwanted mod wheel event in there out, since wheel moved while playing. It was not possible to remove in StudioOne even removing the last node, I had to move it to Sonar and fix this.

Downloaded Cakewalk by Bandlab and will install now and see what happend last 4 years since last update of my Sonar.

EDIT: So I moved permanently to Cakewalk now, almost forgot how good it is.

No messing with forcing automation on midi, it's recorded and kept as events. Or you can decide to convert to track automation later if you want that for certain midi cc. Even select and range of clips at the same time doing that.

And also seeing at least a handful of my feature requests for StudioOne are already in Cakewalk.

Video is as low on resources too, and thumbnails. Very clever use of marker track as well - you decide on each marker if locked in time, or follow musical tempo grid.

Control grouping is freedom in itself, any control can be part of a group - you can mix as you please - mute buttons mixed with solo buttons or whatever you can come up with. And they keep their state as you create grouping - so some toggle on while others toggle off etc. But you can go wrong mixing a button with a knob etc - but it's up to you to figure it out.

And looks on Cakewalk is really professional, and even has a theme editor to modify a lot apart from coloring just about everything right in Cakewalk preferences.

StudioOne worked really well for me though, good daw. Just some choices made about midi that are really weird in my view. Completely unusable as I found this.