Realtime recording and steps

[Adam Wilson]

Hi all, first post here.

I learned about the Octopus last weekend, and I’m very impressed! Browsing the manual, I have a few questions that no doubt you guys can answer.

1. I understand that realtime midi input can be recorded in a track, and the timing will be kept intact as much as possible. Right? How does this translate to – say – the 16 steps of a track? Suppose I record some wild playing with free, off-the-beat timing, and many more notes than 16, but all within the period of one track cycle. What is the result? Will everything be hard-quantized to the nearest step? If not, what does a single step on this track represent?

2. Suppose I start with an empty, default track. The cursor light moves equally fast over the track. Now I change the LEN of some step to 1 full bar, while the others are at their default 1/16th. Does this change the total time it takes for the cursor to scan the track? That is, will the cursor stay longer on this long step? In other words, does a step represent a (group of) note(s), and not so much a fixed period in time?

3. What’s the quality of the switches and pots used in the hardware? Normal, high, cheap stuff? The idea of having a zillion of these babies replaced after some time is not very tempting.

4. Is the OS indeed open source? I’m a senior software engineer for embedded pro audio/video gear, mostly Linux based. You’ll understand I’d love to have a look and be able to tweak. Not that I think it’s needed!

Thanks,
Robert

Post edited by: robert, at: 2007/10/16 09:15

[gseher]

Hello Robert,
some short answers to some of your questions below:

1) Starting with a blank track (all steps are off), by default the incoming notes are recorded on the position where you play them, within a resolution of 1/192. This basically defines the STA value for the just activated step.
The next time a note falls on this active step (or rather within the 12/192 time interval of this step), the pitch will be "stacked", effectively forming a chord, the beat offset will be discarded.

2) A step represents a note, not a period in time. LEN will therefore determine the time it takes for a note off to be sent for that note, but will not influence the time it takes until the next note on.

3) Our users are more suited to answer that question.

4) The OS is open source. See the link provided in the service area of the web site. Or check out http://sourceforge.net/projects/genoqs/

Cheers,

Gabriel

[Adam Wilson]

Hi Gabriel, thanks for the reply.

Regarding #1, I think I understand now:

The Octo’s resolution is 192 units per *whole* note, not 192 PPQN, as I initially assumed (so the Octo has 48 PPQN reso). One step of a 16-step track at normal speed covers 192/16=12 of these units.

When doing a realtime recording into an empty track, an incoming note is assigned to the step currently being scanned, and the note’s timing offset relative to the metronome beat is stored in the step’s STA parameter, if it is not yet defined. That’s how the Octo is able to recreate the timing of the original midi input, within the given resolution of course.

Now as long as notes from the live input are recorded in fresh, new steps of the track, the note’s timing is recorded fine. However, if two or more notes ‘hit’ the same step in the track, all those notes will be stored with the same STA value, since STA is a property of the step, and not a property of each of the multiple notes that can be stored in a single step.

Correct?

Regarding #2, is there a way to change the time between steps? For instance, can I have a track of 1/16th notes, except for step 5 which is 1/4 of a note long? That is, can I change the speed of the scanning cursor on a per-step basis?

Thanks in advance,
Robert

[Adam Wilson]

And to continue on #1, the realtime recording topic, what would be the consequence of storing an offset to the step’s STA property in each of the notes stored in a single step?

Imagine each note has it’s own STA property, stored as an offset to the step’s STA property. Imagine this note property CANNOT be edited in any of the pages, and it’s zero per default. That’s how the Octo works right now I assume. Now imagine that the note’s STA property is only written during realtime recording. Would the playback engine be able to handle this?

The same can be done with other props of course, like VEL.

Just a wild thought.

[gseher]

Hi Robert,

Re. #1:
You are absolutely correct.

Re. #2:
It depends.
You could use the direction editing feature to have the cursor stay on a step longer than 1/16 note. In fact it may stay there up to 9/16 of a note, in 1/16 intervals.
In the current implementation however, it would trigger an active note on that step every 1/16. In your scenario, if step 5 is active, it will just be played 4 times (4/16).

Gabriel

[George Stobbelaar]

robert wrote:

Quote:

3. What’s the quality of the switches and pots used in the hardware? Normal, high, cheap stuff? The idea of having a zillion of these babies replaced after some time is not very tempting.

I can’t give a long-time-experience account but compared to all my other hardware the switches and potis of the Octopus are excellent. Both are metal, the switches are tightly embedded in the surface but reacting very tight. So you can glide over them without "feeling insecure". The potis have a quite strong raster which is convient for counting steps and are rock solid.
I am no engineer but I feel very secure and comfortabel with the hardware (it feels much better than my nord modular G2)

Best wishes

[gseher]

robert wrote:

Quote:

And to continue on #1, the realtime recording topic, what would be the consequence of storing an offset to the step’s STA property in each of the notes stored in a single step?

Imagine each note has it’s own STA property, stored as an offset to the step’s STA property. Imagine this note property CANNOT be edited in any of the pages, and it’s zero per default. That’s how the Octo works right now I assume. Now imagine that the note’s STA property is only written during realtime recording. Would the playback engine be able to handle this?

The same can be done with other props of course, like VEL.

Just a wild thought.

Well, maybe not that wild after all – this is sort of related to the way strumming works right now (check out the description in the manual).
Basically, strumming is modeled as an offset in the STA for the notes making up a chord on a step. But the offset model may be applied equally to STA, VEL or PIT.

Gabriel

[Adam Wilson]

gseher wrote:

Quote:

Hi Robert,

Re. #2:
In the current implementation however, it would trigger an active note on that step every 1/16. In your scenario, if step 5 is active, it will just be played 4 times (4/16).

I see…
Would it work with events for track playback speed then? Is playback speed supported in the event mechanism?

[gseher]

robert wrote:

Quote:

gseher wrote:

Quote:

Hi Robert,

Re. #2:
In the current implementation however, it would trigger an active note on that step every 1/16. In your scenario, if step 5 is active, it will just be played 4 times (4/16).

I see…
Would it work with events for track playback speed then? Is playback speed supported in the event mechanism?

Events are available for the 10 track core attributes only (see labeling on the matrix rows). Track clock multiplier is not one of them.
Anyway, for the proposed "analog" sequencer usecase, a dedicated implementation model would likely be more suitable.
At a programming level, it would imply an extension to the cursor advance engine, at an interface level at least a switch selecting between "legacy" and standard play mode of a track. Nice you proposed there!

[Adam Wilson]

lebenspuls wrote:

Quote:

I can’t give a long-time-experience account but compared to all my other hardware the switches and potis of the Octopus are excellent. Both are metal, the switches are tightly embedded in the surface but reacting very tight. So you can glide over them without "feeling insecure". The potis have a quite strong raster which is convient for counting steps and are rock solid.
I am no engineer but I feel very secure and comfortabel with the hardware (it feels much better than my nord modular G2)

Thanks for this info. Looking good!

Nice G2 reference. I have a G2x sitting here, begging to be controlled from the Octopus. I originally wanted to use the G2 for extensive sequencing, but I hit the roof (resource wise) when I tried to roll my own stuff, and the interface is not optimal. Using it as a complex sound source however, plus Octopus driving it… oh man.

Post edited by: robert, at: 2007/10/18 16:02

[Adam Wilson]

gseher wrote:

Quote:

Events are available for the 10 track core attributes only (see labeling on the matrix rows). Track clock multiplier is not one of them.
Anyway, for the proposed "analog" sequencer usecase, a dedicated implementation model would likely be more suitable.
At a programming level, it would imply an extension to the cursor advance engine, at an interface level at least a switch selecting between "legacy" and standard play mode of a track. Nice you proposed there!

Too bad the track clock specifiers cannot be addressed from events. Could have been fun!

Regarding legacy/standard play mode, the best option of course would be to not have any mode added to the system and find some standard way to implement steps with a variable size, but defaulting to the standard 12 ticks per step. That would mean however that a track no longer has a fixed size of 192 resolution ticks, but now depends on the accumulated sizes of each of the steps. Sounds kinda drastic, heh.

[gseher]

Good point.
In that case, the logical place for such a parameter seems still to be in the direction model i.m.o.

[Adam Wilson]

gseher wrote:

Quote:

Well, maybe not that wild after all – this is sort of related to the way strumming works right now (check out the description in the manual).
Basically, strumming is modeled as an offset in the STA for the notes making up a chord on a step. But the offset model may be applied equally to STA, VEL or PIT.

Cool! So the per-note STA/VEL properties are already in the design? That means the playback engine already supports these, great.

So.. during realtime record, it would be easy to fill these per-note STA/VEL slots, instead of using only the single step STA property. That would transform a track into a 48 PPQN midi recorder. This would also reduce zipper noise for recorded CCs, I guess.

To clear these per-note STA/VEL offsets to get all notes play as a single chord, one could probably toy with the STRUM feature. Just guessing.

I didn’t have a look at the code yet, and probably will delay that until I have the hardware. And I have at least 2400 reasons to think really hard about getting the hardware… I’m still very interested though.

One of the other reasons is that I’d like the Octo to behave as both step sequencer and as a polyphonic midi recorder, as you find in DAWs. Looks like everything is there.

Post edited by: robert, at: 2007/10/19 11:54

[Adam Wilson]

gseher wrote:

Quote:

Good point.
In that case, the logical place for such a parameter seems still to be in the direction model i.m.o.

If the cursor movement (i.e. next step decision) is neatly tucked away in a separate piece of code, and the rest of the software is unaware of the 12 ticks/step and 192 ticks/track relationship, it should be relatively easy to implement the new step TIME property.

Note that imo step TIME and step LEN are two very different things. The first is the number of ticks the step takes before the cursor moves to the next step. Default TIME is 12 ticks, but could be anything (but > 0 I guess). Changing the TIME property can easily result in tracks having a total time not equal to the standard 192 ticks.

Step LEN is the step’s gate time, the time between note on and note off. It’s normally <= TIME. For staccato notes LEN is much shorter than TIME. To get the auto-legato mode on most synths, LEN should be set > TIME, as recently discussed elsewhere on this forum.

Problem with adding nice new basic properties is the UI. Since the front panel is so nicely dedicated to the original design of the firmware, how do you add stuff like this? Hardware with LCD interface simply add another page for added stuff. Tough…

Post edited by: robert, at: 2007/10/19 11:52

Post edited by: robert, at: 2007/10/19 11:56

[gseher]

Quote:

Cool! So the per-note STA/VEL properties are already in the design? That means the playback engine already supports these, great.

Well, not quite.
The strum is using a different piece of infrastructure, which is global. The strum levels per step can be individual, but the effect for each strum level (i.e. offset value) is global.

Quote:

So.. during realtime record, it would be easy to fill these per-note STA/VEL slots, instead of using only the single step STA property. That would transform a track into a 48 PPQN midi recorder.

If that is the use case we are after, it could be done, but using several tracks at the same time.

Quote:

This would also reduce zipper noise for recorded CCs, I guess.

There is a solution for this in the next OS release.
(oops!!)

[Author]

Posts