Groove, – a suggestion

OS_CE Forums Octopus User exchange Groove, – a suggestion

Viewing 10 posts - 1 through 10 (of 10 total)
  • Author
    Posts
  • #743
    gseher
    Keymaster

    Though I am still very new to the Octopus, I am "not-so-new" to making music, and there is already one thing about the Octopus (feature-wise)that I would like to mention. In fact I noted this thing already months ago when I borrowed an Octopus for a day.

    It is about the Groove parameter (GRV).

    As it is now, turning up the GRV knob moves the even steps ALL THE WAY to the following uneven step. I understand the thought behind this when I look at the Octopus as an experimental music machine.

    However this creates a limitation if you want to work with more down-to-earth implementations of the concept of groove. This limitation comes from the fact that when building a musical rhythmic pattern in styles deriving from the afro-american roots (which covers pretty much all music that has "a groove"), there is one area of subdivision that has more importance than anything else.
    That area is BETWEEN the straight and the triplet (shuffle or swing) feel. (In notational terms between (if we are talking 16th-notes) normal 16th-notes and triplet 16th-notes where the first two 16ths are tied together.)
    This area is the playground of the true masters of swing. Whether we are talking about (just to name a few) Prince, Sly&Robbie, Neville Brothers, Neptunes, Quincy Jones, Beck or Massive Attack, that little area between straight and swing has gotten a lot of attention, consciously or intuitively.

    So what is the limitation I am talking about: The thing is, that with only 16 parameter steps to take us from straight to "sitting-on-top-of-the-next-note", the area mentioned above is covered in the first 3 or 4 steps. So when working with "normal" implementation of groove we have only 3 or 4 levels of "swing" to choose from, and this I feel is a limitation (of the not so nice kind).

    Pretty much everything that came after the famed TR-909 has had a real or vitual "swing" knob, that in fine increments lets you set the exact "swing" amount that you need. And that tradition definitely leaves me wanting more than 3-4 "swing" levels.

    In case my feelings here resonate in the Octopus Society, here is my humble suggestion:

    Solution 1:

    Decrease (cut in half actually) the range that even steps are moved. So we go from "16´th + 16´th" (no GRV) to "dotted 16´th + 32´th" (max GRV).
    This is exactly the way that the "groove amount" in Ableton Live (and others) works.
    This would give the "really interesting range" 6-8 steps which is, – well, twice as good. Not "the ultimate", but a really good improvement.

    The good thing about this solution is that RAM demands would be status quo (I suppose).
    The compromise is that you sacrifice the range between "dotted 16´th + 32´th" and "sitting-on-top-of-the-next-note". I would happily pay that price though!

    Solution 2:
    Keep the range, but double the number of increments to 32, using a different led colour for 17-32.
    The result will be like Solution 1, but without the sacrificed range. However, this will probably (I am no programmer!) double the RAM demands.

    It would be interesting to see if other Octopussians have had similar thoughts, and off course to hear what our Masters say:)

    Post edited by: LDT, at: 2008/04/05 15:45

    #1363
    gseher
    Keymaster

    Hi Lars,
    first off, many thanks for the nice background, as to why this is desirable, and I must say that I can fully follow. Yet another great discussion, alongside with the one we have had on chords.

    Before going from my end into the ways to solve it, let me give you the cold sight of the programmer on this. Octopus has an internal resolution of 1/192 of a note. That translates to 12 possible positions between two steps of 1/16th. Why GRV can get up to 16 is a separate question for now, let’s focus on the 12 segments.

    That is the current setup as of right now and I need to reflect a bit on how your proposed solutions may be mapped. Any thoughts in the meantime are welcome!

    Cheers, Gabriel

    #1367
    gseher
    Keymaster

    Ah, I didn´t think of clock resolution at all, haha. I see it is not so easy then.

    #1369
    Gene Schwartz
    Participant

    This was a very interesting post indeed, and I really understand where LDT is going, and a goal definately worth of trying to reach. Although I also understand the technical problems – if I understand it correctly the way would be to change the resolution of the sequencer, something that would (my guess here) require a more or less a total rewrite of the OS.

    But wouldn’t it be possible to achieve this in another way? After reading this post my head jumped to quantum mechanics! Where things can be at more than one place at the same time.

    Hey – I’m not a programmer (not any more at least) so maybe I’m just talking rubbish here – but wouldn’t it be possible to achieve a higher resolution by doing some kind of interlacing? That would probably push the cpu hard, so it’s probably not the most efficient solution – but hey… you asked for ideas :)

    /Carl

    #1377
    gseher
    Keymaster

    Well, increasing the resolution of the sequencer could be achieved in at least two ways I can think of now, but one of them (the more promising one) is something I would really need to build a experiment for. The other one bases on the current model and seems very CPU heavy, but still worth validating.

    What needs to be rewritten in the way the sequencer events are generated and put into the sequencer queue, and the way the sequencer queue is then played back.
    There is a component of latency that I need to investigate an experiment. The OS values in the specs are good, but I need to see it running, and hear it play. Realistically, that looks more like a summer project rather than a quick fix.

    Ok, some years the summer comes earlier, especially in these days.. so will keep you posted on any progress / realization I manage to achieve at that front.
    Cheers,
    Gabriel

    #1381
    gseher
    Keymaster

    i thought the original poster was being too overlly critical with the groove parameter regarding the pus. but now i see what he’s saying. there is that tiny amount between knob steps that i really want. it’s like "right there…" and i can’t hit it. it’s either too much or not enough and if i could just push it farther or behind, i’d be golden. if i drill into the step and push of pull it back, it doesn’t really help. i’m starting to see this more and more now.

    i’ve started now see if i can get that feel now in ableton 6. which i think i gave up on too early. maybe the combination of ableton and the pus is what i need

    #1382
    gseher
    Keymaster

    i thought the original poster was being too overlly critical with the groove parameter regarding the pus. but now i see what he’s saying. there is that tiny amount between knob steps that i really want. it’s like "right there…" and i can’t hit it. it’s either too much or not enough and if i could just push it farther or behind, i’d be golden. if i drill into the step and push of pull it back, it doesn’t really help. i’m starting to see this more and more now.

    i’ve started now see if i can get that feel now in ableton 6. which i think i gave up on too early. maybe the combination of ableton and the pus is what i need

    #1383
    Adam Wilson
    Participant

    gseher wrote:

    Quote:
    Well, increasing the resolution of the sequencer could be achieved in at least two ways I can think of now, but one of them (the more promising one) is something I would really need to build a experiment for. The other one bases on the current model and seems very CPU heavy, but still worth validating.

    What needs to be rewritten in the way the sequencer events are generated and put into the sequencer queue, and the way the sequencer queue is then played back.
    There is a component of latency that I need to investigate an experiment. The OS values in the specs are good, but I need to see it running, and hear it play. Realistically, that looks more like a summer project rather than a quick fix.

    Picking up some missed threads here. Stupid forum software silently logs me out after some time and I think nothing’s happening. ;)

    Anyway, I think I’d prefer to tackle the resolution problem with timestamping the outgoing midi events in a sorted queue, and have a high reso timer walk down the list to see what has to go out.

    The sequencer code can then run at a much lower reso as long at it manages to correctly timestamp the midi data it queues.

    Fun project! Definitelty not a quicky. ;)

    #1698
    gseher
    Keymaster

    Robert, your proposed method is definitely worth investigating, especially in the light of parallel discussions we had about the way the main player loop works now.

    #1700
    Adam Wilson
    Participant

    gseher wrote:

    Quote:
    Robert, your proposed method is definitely worth investigating, especially in the light of parallel discussions we had about the way the main player loop works now.

    Hi Gabriel, yes, I had the same thought. It could be a good time to combine both projects, if possible.

Viewing 10 posts - 1 through 10 (of 10 total)
  • You must be logged in to reply to this topic.