[gseher]

Thanks a lot – very interesting indeed and a worthwhile reading (if you can call that a forum these days) !

[gseher]

I found this great thread on SOS where Bill Williams (of Zyklus fame) and Stephen Kay (of Karma Fame) have a flame exchange on each other technology.

Thought you might have been interested.

[gseher]

Transpose

Hi now I know it: Press Record, Press the Track or page button and than transpose with your connected keyboard.

[gseher]

Hi John,
I have not evaluated this path to the extent that I can comment.
If you have a clearer view on the potential benefits than I do at the moment, I’ll be happy to discuss.
Cheers,
Gabriel

[gseher]

Hello,as far as I know this is a known bug in the actual version and will be fixed within the next version.

[gseher]

In 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!

[gseher]

Quote:

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.

[gseher]

Quote:

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.

[gseher]

Quote:

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.

[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!!)

[gseher]

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

[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!

[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

[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

[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

[Author]

Posts