Re: Re:Realtime recording and steps

OS_CE Forums Octopus User exchange Realtime recording and steps Re: Re:Realtime recording and steps

#1252
Adam Wilson
Participant

gseher wrote:

Quote:
Quote:
Btw, I don’t understand the ‘several tracks at the same time’ bit above. A single track *can* record polyphonic data, right?

Yes.
But to avoid any misunderstanding: a single track can record polyphonic data, in the sense that it can record chords on its steps.
Remember that stacking notes on a step will result in a chord, and not a sequence of separate notes. Now programmatically, a chord is a step that plays its NOTE ON several times at once, but at different pitches. Then, variation can be induced using strum, varying STA, VEL, etc.

Okay, I see I’m still on track.

What I’m trying to find out here is if it would be possible (e.g. for me in my own version of the code) to expand the above so that polyphonic recording in a single track would result in true polyphonic playback, at the good old reso of 48 PPQN.

Based on your description, I guess that when the playback cursor hits the next step, it spits out all the notes stored in that step. Those notes probably end up in some sort of MIDI output queue. The added strum feature suggests that those notes can be queued with individual STA, VEL, etc parameters, based on an algorithm. That is, these STA, VEL, etc per-note parameters needed for the strum feature are synthesized on the spot when the MIDI data is enqueued, ready for playback. This also means that the receiving MIDI queue already supports my devilish plan. Right so far?

Okay, the problem lies in the realtime recording phase. As discussed earlier in this thread, all the notes that are stored on a single step share the step’s single STA/VEL, etc. value. The first incoming realtime note that hits an empty step defines the STA value for all the other notes that hit the same step.

So here’s the big question: How easy would it be to add STA (and maybe VEL) params to each of the notes in the data structure and design, so that these can be filled when a realtime recorded note hits the step? These note properties would of course be relative to the associated step properties. It’s simply one more zoom level. In my imagination it should be not too much work and it wouldn’t break the current feature set.

Playback would be easy. Instead of using the step’s STA and VEL properties, you’d take those stored with the note. And if the strum feature is used, you’d simply ignore the STA/VEL values stored in the notes. Maybe you’d want some command that clears the note’s STA/VEL properties.

So would this be doable?

Damn, I’d love to tweak the code, try it on my Octo, and commit the changes for approval by you guys. Well, maybe not too long.