Cubase 7 To Cubase 9.5 Upgrade Questions

[Ph-J]

I always found the floating transport bar annoying.

+1, forgot that one

[jancivil]

And another thing I have been wondering about - what does project length really mean for Cubase?
Default is 10 minutes - what happends if that is exceeded?

You talked about lengthy midi recordings, and thought if it applies to your problem somehow?

For midi there is 24 midi clocks each quarternote - so wonder if better that set resolution is multiples of 24.
Most common I've seen in computer sequencer is 960, or default in Cubase was 480 as I recall.

For MIDI *CLOCK*. I don't know what actual relevance MIDI Clock has to the workings of software sequencers in 2018. Or 2002 for that matter.

I'm doing 1000 per 16th because:
1) highest possible resolution for detailed working.
2) I can do arithmetic in my head better if it's 10, 100, 1000, etc., and/so it's 1000 per 16th.
So, right now I don't have decent latency at_all, so, if I'm going to pencil or move notes in order to obtain, say 25 in the time of a quarter note this is 4000 divided by 25 (to use one I can't really form a grid for).

I didn't mention lengthy MIDI length, my longest (based in MIDI) project ever is around 10 and a half minutes. However I have done the whole album in stems [edit: eg., 35 m.] and I don't think there's any problem. I am constantly annoyed by Cubendo expanding my project length for me when I make certain changes. I realize when automation is written past 'end' it will do, but oftimes I just don't know why.

I mentioned having to make something hundreds of times longer than it ended up being by this strange bug.
Being that I never saw it before, it wouldn't make a lot of sense to second guess my display resolution since the early part of the century. I never saw it in Cubase at all. Nuendo had another odd bug appear which was resolved in 8.2.1, it wouldn't delete audio from the pool, believing wrongly that it existed in another pool. Now it actually deletes the EDITS when I bounce and replace an audio event. Could be a feature, not a bug. It suits me as that's what I'm actually after when I bounce, to commit and clean things up. This USED to be something you could decide by archiving the pool's contents. And is a main reason I bother to do 'Backup Project'. They keep fugging with stuff.

[jancivil]

I always found the floating transport bar annoying.

+1, forgot that one

F2 for on, F2 for off, toggled.
I'm annoyed by the whole concept of Right Zone!
Toggled by the extremely difficult command/option R!

[Scotty]

As long as you are 100% "in the box" midi clock doesn't matter but if you work with external gear with internal sequencers or midi tempo based effect processors, midi clock is highly relevant.

For MIDI *CLOCK*. I don't know what actual relevance MIDI Clock has to the workings of software sequencers in 2018. Or 2002 for that matter.
.

[lfm]

For MIDI *CLOCK*. I don't know what actual relevance MIDI Clock has to the workings of software sequencers in 2018. Or 2002 for that matter.

I think all tempo for plugins a governed by midi clock. Any tempo you have is driven by 24 midi clocks each quarternote.

Many plugins have ability to do delays/doublers and other stuff based on tempo, or tempo/4, tempo/16 and similar.

Arpeggiators etc. Everything tempodriven depend on midi clock. That's how I understand it.

So think even divided by 24 is good as resolution, or there might be quirks in timing due to truncation in between.

And when using logical editor or transformer and do various operations that position midi events on bars - using the ppq is some way - calculations may be odd.

Since external midi gear have to activate sending midi clock to it - not to clutter midi cable if not needed - very important. But relevant internally too and always there.

All to my understanding - correct me if I am wrong.

[jancivil]

For MIDI *CLOCK*. I don't know what actual relevance MIDI Clock has to the workings of software sequencers in 2018. Or 2002 for that matter.

I think all tempo for plugins a governed by midi clock. Any tempo you have is driven by 24 midi clocks each quarternote.

Many plugins have ability to do delays/doublers and other stuff based on tempo, or tempo/4, tempo/16 and similar.

Arpeggiators etc. Everything tempodriven depend on midi clock. That's how I understand it.

All to my understanding - correct me if I am wrong.

I will show you a picture and ask the question by particulars. Here I depict one quarter note duration of bar 23, beats 1 thru to 2. I chose a preset I made in the Quantize Panel "1/8 Triplet 13-let"; the idea of that is 13 in the time of a triplet 8th. There are three of those in the time of a quarter note. Hence there are 39 displayed there now under that selection in Quantize, as a sub-grid inside of a quarter note.

time subdivision.png

Can you explain to me the dependence of this 'clock' on the number 24?
(This is just one thing, that happens to be a saved preset at the moment. I have not even begun to make them for every possible thing, I've forgotten if I ever have found out where it's going to indicate 'no more'.)

And SMPTE is my secondary Ruler basis, that is when Bars and Beats is primary. Could go vice versa with it.
SMPTE: 24? 25?; 23.98, 24.98? 30 Frames per second, etc. 50, drop frame 50, 60.
And so I may quantize-set the grid in project window or an editor window to any of the above. Here is 23.98 fps with subframes displayed (as the primary display): @ 79 subframes, it rolls over as though to 80 and it's 2:33:01.00.
Happened to be the last video I worked with, I didn't mean to subvert 24 so inhumanely.

SMPTE to subframes.png

These are all valid divisions of the timeline for all practical purposes. But before I got into this, I stated, and as a fact, I am using 1000 pulses per 16th note; and I don't remember making any other decision, or working any other way in 15 yrs. 1000 is not a product of 24. I would say that 480 or 960 is 'legacy' reference. Other grids do appear to work.

So am I missing something? <Divisions of the timeline> seems to be a definition of <clock>. SMPTE is not MIDI. Cubendo is not a hardware synthesizer. Somehow I believe my understanding is working here. Correct me where I'm wrong.


edited for grammar and syntax errors.

[jancivil]

As long as you are 100% "in the box" midi clock doesn't matter but if you work with external gear with internal sequencers or midi tempo based effect processors, midi clock is highly relevant.

For MIDI *CLOCK*. I don't know what actual relevance MIDI Clock has to the workings of software sequencers in 2018. Or 2002 for that matter.
.

I thought 'to the workings of software sequencers' indicated 'per se', ie., through itself. A belief was indicated that all of Cubendo's tempi are governed by 24 ticks per quarter note 'because MIDI', which was the context for that remark. I don't think this software is 'governed' by MIDI Clock.

[Ph-J]

F2 for on, F2 for off, toggled.
I'm annoyed by the whole concept of Right Zone!
Toggled by the extremely difficult command/option R!

Yeah, I know for F2 but it's the floating thing that bugged me. Wherever I placed it it always ended up in the way at some point

I have to admit I (almost) never use the Right Zone.
Lower Zone on the other hand, I got used to very fast.

[lfm]

Can you explain to me the dependence of this 'clock' on the number 24?

The resolution - in your case 1000 ppq govern how how many positions a midi event can take in a range of one quarternote.

So let's say a humanize thingy on a range of midi events - can take advantage of what you set as resolution.

Then comes the transport according to the set tempo over that note - and a plugin like an arpeggiator that tell the host it wants midi clock since it's driven by tempo. Arpeggiator will receive a midi clock 24 times over that duration that may have midi events placed anywhere from 0->1000 ticks due to humanize function I took as example.

But since 1000 is not a multiple of 24 - you will not get every event position we can think of played at an even rate over time as the timeline is played back. At some point it can be truncated and played a midi clock(24th) early.

If ppq resolution were 960 - it would play back at the proper 24th every bar through.

I doubt any of use will notice in a way that we:
- crap this sound completely out of sync
- I can't listen to this anymore, stop, stop, stop

Still this is very short jump in time, but certainly enough to be heard if we consider the timing that we often use for the humanize features.

It probably is possible to position 16 bars of events at tick 980 and look at what position it is played back at by rendering an arpeggiator to a new midi clip. You render to audio as well and have a look and what sample it playes back over time.

So math tells me it's a good idea to stick to multiples of 24 for set resolution. Example here doing humanize on something that is to be played by arpeggiator is not how we do it probably, just for explaining a bit.

Working on my drum skills - doing more and more in the pocket playing - I also developed better and better hearing of the beat. And usually don't do anything to drums played. But for keyboards stuff I may.

Anyways, my take on the matter. It makes sense to me to stick to multiples of 24. And I very soon got comfortable with editing and looking at odd number offsets not being decimal.

And if using external gear with arpeggiator or something else tempo driven - it's worth considering.

[jancivil]

Can you explain to me the dependence of this 'clock' on the number 24?

The resolution - in your case 1000 ppq govern how how many positions a midi event can take in a range of one quarternote.

So let's say a humanize thingy on a range of midi events - can take advantage of what you set as resolution.

Then comes the transport according to the set tempo over that note - and a plugin like an arpeggiator that tell the host it wants midi clock since it's driven by tempo. Arpeggiator will receive a midi clock 24 times over that duration that may have midi events placed anywhere from 0->1000 ticks due to humanize function I took as example.

But since 1000 is not a multiple of 24 - you will not get every event position we can think of played at an even rate over time as the timeline is played back. At some point it can be truncated and played a midi clock(24th) early.

If ppq resolution were 960 - it would play back at the proper 24th every bar through.

I doubt any of use will notice in a way that we:
- crap this sound completely out of sync
- I can't listen to this anymore, stop, stop, stop

Still this is very short jump in time, but certainly enough to be heard if we consider the timing that we often use for the humanize features.

It probably is possible to position 16 bars of events at tick 980 and look at what position it is played back at by rendering an arpeggiator to a new midi clip. You render to audio as well and have a look and what sample it playes back over time.

So math tells me it's a good idea to stick to multiples of 24 for set resolution. Example here doing humanize on something that is to be played by arpeggiator is not how we do it probably, just for explaining a bit.

Working on my drum skills - doing more and more in the pocket playing - I also developed better and better hearing of the beat. And usually don't do anything to drums played. But for keyboards stuff I may.

Anyways, my take on the matter. It makes sense to me to stick to multiples of 24. And I very soon got comfortable with editing and looking at odd number offsets not being decimal.

And if using external gear with arpeggiator or something else tempo driven - it's worth considering.

In other words you can't explain it.
You're actually gaslighting me. I'm supremely confident of my perception of time. I do many things, and there is no such problem. Rendering an arpeggiator/arpeggiator from MIDI Clock is special pleading, it isn't going to prove anything about anything else. It (and 'you will not get...') is designed strictly for to suit your argument, which is a known fallacy: Circular Argument/Begging the Question. Seriously. Math itself is not determining that, you have a supposition based in this one number that you're circling back to in every case.

I have yet to use an arpeggiator plug-in. (I have used them in a Kontakt instrument where I went for very irregular, in fact for error and humanization; NB, I was interested in the number 5.) I would tend to doubt that a plugins coder is going to verify your 'all is dependent on 24 PPQN' (I went into SMPTE to free us from the consideration of pulses per quarter note, for instance, but no) supposition, but I don't understand what I read from that sort of thing so well, I can't verify anything really. But I'd be amazed to see that supposition verified objectively as to how plugins work in a DAW per se. Plugins are typically expected to report latency. Does that too rely on the number 24? That is not meant strictly as a rhetorical question, I really have no idea what you're on about. I should have put it bluntly, 'where do you get this notion from', is is just some knowledge that you like bandying about?
"||:I know what I like/and I like what I know:||" - Genesis.

It looks as though you expect the software to balk, and error necessarily produced in working with numbers that are not a product of 24.

But prove me wrong with absolutely faultless renders because product of 24 vs faulty renders which can somehow be shown to be because not product of 24. And good luck with that.

[jancivil]

I [...] usually don't do anything to drums played.

I do, though, all sorts of editing of MIDI to drums played in, to drums tracks created in the key editor, in the drum editor...

It's particularly strange to see you bring in 'humanize by' your supposition of product of 24, since I effect that certainly with maximal subtlety simply because the highest possible resolution is available. No particular difficulty arises out of ignoring product of 24 in the display resolution*. Don't tell me it does, telling people what their experience is because it must match your argument is called gaslighting, and it's not a nice thing.
I'm creating an illusion which is totally based in reality and reality is not dependent on the number 24. I've been a drummer in the world, if my experience hearing it in the box matches that, there is no special pleading that means anything, IE: either this is demonstrable by a result or it isn't. And as far as I can determine that *proof is going to lie in the realm of 'sample-accurate' to begin with. Which is why, to be candid, I said 'good luck with that' (exercise). You're barking up a quite unreal tree, frankly.

[lfm]

It looks as though you expect the software to balk, and error necessarily produced in working with numbers that are not a product of 24.

But prove me wrong with absolutely faultless renders because product of 24 vs faulty renders which can somehow be shown to be because not product of 24. And good luck with that.

You can choose to be offended if you like, I was trying to explain why every sequencer, since the 80's, I encountered either had 96, 480 or 960 as resolution for midi. All being multiples of 24.

And to me it makes perfect sense due to how midi clock is constructed - 24 clocks every quarternote.

Cubase has export settings for midi 24-960 as resolution.

If not using any plugins or external gear driven by tempo - it does not matter - and you will probably not encounter any problems running in 1000 ppq.

But since you had some weird issues where Cubase started to create strange things, I mentioned this FYI. In there might be some calculations made that get truncated numbers - as one of many things that contribute to weirdness.

Maybe Cubase internally handle everything to sample accurate - I don't know.

I just never had an issue with using the 960 numbers and felt no need to deviate from that. And any presets made for Logical Editor and Transformer would also be ok since they probably rely on 24-multiples.

There was a thread here a couple of years ago where one guy wanted a preset positioning all markers on nearest bar - that seemed to be dependent on set resolution. You get current position as ticks(ppq) from start of project.

That's where I got the idea from that using 4000 ppq might create overflow of some sort.

I'm sorry if I lack the pedagogic skills to explain this 24-thingy to everybodys satisfaction - without they start to be offended for no reason. I had no intention other than to help - but too often in too many words.