OS_CE › Forums › Octopus › User exchange › Groove, – a suggestion
- This topic has 9 replies, 3 voices, and was last updated 16 years, 3 months ago by Adam Wilson.
-
AuthorPosts
-
April 5, 2008 at 12:24 #743gseherKeymaster
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
April 7, 2008 at 09:02 #1363gseherKeymasterHi 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
April 7, 2008 at 17:49 #1367gseherKeymasterAh, I didn´t think of clock resolution at all, haha. I see it is not so easy then.
April 9, 2008 at 09:50 #1369Gene SchwartzParticipantThis 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
April 10, 2008 at 05:11 #1377gseherKeymasterWell, 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,
GabrielJuly 13, 2008 at 22:02 #1381gseherKeymasteri 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
July 13, 2008 at 22:07 #1382gseherKeymasteri 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
July 17, 2008 at 05:02 #1383Adam WilsonParticipantgseher 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.
July 17, 2008 at 08:44 #1698gseherKeymasterRobert, 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.
July 17, 2008 at 09:26 #1700Adam WilsonParticipantgseher 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.
-
AuthorPosts
- You must be logged in to reply to this topic.