Adam Wilson

Forum Replies Created

Viewing 14 posts - 151 through 164 (of 164 total)
  • Author
    Posts
  • in reply to: Feature request: Random pick from chord pool #1441
    Adam Wilson
    Participant

    But would that guarantee that no more than N notes are generated for given step, when each of the strummed notes has its own probability value? Theoratically, this could mean that all notes get strummed, or zero.

    This is all from my understanding that the strum feature only specifies the distribution of notes over time, not so much the amount of notes being played.

    in reply to: Feature request: Random pick from chord pool #1439
    Adam Wilson
    Participant

    Thanks Lars.

    One optional addition could be a randomize amount factor, something like AMT.

    With the factor set to zero, the track still outputs no more than N voices, but in a reproducable manner: simply using the first N pitch values stored in the step (if present). With the factor set to full, we get a full random behavior.

    Now when playing my example C – E – G sequence, and randomise factor set to zero, it plays C – E – G in 100% of the cases. But opening the factor a little bit will introduce the alternative C – F – G sequence only now and then, like an occasional mutation. Opening the factor slowly to full results in a 50/50 chance in getting both variatons.

    in reply to: Source code? #1269
    Adam Wilson
    Participant

    There’s a development tutorial? Oops, I missed that indeed. Thanks for the hint. ;)

    in reply to: Source code? #1267
    Adam Wilson
    Participant

    Thanks Gabriel, I’ll check them out. Super cool to have the sources available. :)

    I vaguely remember you develop on a Mac? Can I ask what tools you use? I’m a diehard linux developer, but also have a mac now, since about a year.

    in reply to: 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.

    in reply to: Realtime recording and steps #1248
    Adam Wilson
    Participant

    gseher 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?

    in reply to: Realtime recording and steps #1249
    Adam Wilson
    Participant

    gseher 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?

    in reply to: Realtime recording and steps #1245
    Adam Wilson
    Participant

    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

    in reply to: Realtime recording and steps #1241
    Adam Wilson
    Participant

    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

    in reply to: Realtime recording and steps #1243
    Adam Wilson
    Participant

    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.

    in reply to: Realtime recording and steps #1240
    Adam Wilson
    Participant

    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. B)

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

    in reply to: Realtime recording and steps #1239
    Adam Wilson
    Participant

    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?

    in reply to: Realtime recording and steps #1236
    Adam Wilson
    Participant

    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. ;)

    in reply to: Realtime recording and steps #1235
    Adam Wilson
    Participant

    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

Viewing 14 posts - 151 through 164 (of 164 total)