OS_CE › Forums › Octopus › User exchange › Realtime recording and steps
- This topic has 21 replies, 3 voices, and was last updated 16 years, 11 months ago by gseher.
-
AuthorPosts
-
October 19, 2007 at 10:57 #1247gseherKeymasterQuote: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…
Many features not foreseen in the original design have found their natural place. In general, while there is a limit to how much a dedicated UI can accomodate, it offers an entirely different experience over an LCD. And LCDs have a hard standing against laptop computers these days – i.m.o.
October 19, 2007 at 11:25 #1249Adam WilsonParticipantgseher wrote:
Quote:Many features not foreseen in the original design have found their natural place. In general, while there is a limit to how much a dedicated UI can accomodate, it offers an entirely different experience over an LCD. And LCDs have a hard standing against laptop computers these days – i.m.o.Good to hear the UI is not a problem for you.
Yes, I fully agree on the Octo’s UI. It’s the most important factor for me to seriously consider one. It makes me understand why some people refer to it as an ‘instrument’. That and the fact that you guys decided to make it a multi-track interface, even though it takes a ton of buttons and space to do that.
Curious, why did you decide to go wild on that panel?
October 19, 2007 at 14:43 #1248Adam WilsonParticipantgseher wrote:
Quote:If that is the use case we are after, it could be done, but using several tracks at the same time.Well it would please me personally to get the Octo as close as possible to a straight MIDI recorder, without interfering with the step sequencer features of course. But since I don’t own a machine, simply ignore at will.
I appreciate the OS is open source. But does this also mean that Genoqs is open to user requests when it comes to the general design and feature set of the machine?
Btw, I don’t understand the ‘several tracks at the same time’ bit above. A single track *can* record polyphonic data, right?
October 19, 2007 at 18:32 #1250gseherKeymasterQuote:Curious, why did you decide to go wild on that panel?Not sure what you mean
Now, if you think the number of buttons is unusual, well, that’s because it turned out to be what it takes to build the instrument we had envisioned.October 19, 2007 at 18:44 #1251gseherKeymasterQuote:I appreciate the OS is open source. But does this also mean that Genoqs is open to user requests when it comes to the general design and feature set of the machine?It depends how far these go, and what they imply for the overall design, or how they can be supported by the actual design.
However, I feel that in the past we were quite accomodating in that respect. Again, users may add some comments to this.The only OS version we can directly support is the one we publish, because that is the one we have fully under control.
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.October 20, 2007 at 08:00 #1252Adam WilsonParticipantgseher 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.
October 23, 2007 at 05:12 #1253gseherKeymasterIn principle, yes, the architecture supports the scenario you propose. No major changes are required here, just a few additions to the engine.
However, it may be a matter of available memory to support the new required footprint.A quick check reveals that you could easily add about 300 bytes per page without running into constraints, or trying to save space at some other end.
At the same time, it is a question of how you want to implement the proposed functionality. Even with a step holding potentially full 7 notes (discrete attribute values), you may run into constraints, depending on the particular use case you have in mind.
In the Octopus model Steps are polyphonic, so they can hold and record chords. Under this consideration, your MIDI recorder approach is probably better realized by having multi-track recording enabled, letting you make use not only of available memory, but also UI real-estate!
-
AuthorPosts
- You must be logged in to reply to this topic.