- This topic has 46 replies, 3 voices, and was last updated 16 years, 4 months ago by
.
-
Posts
-
Ok – got it running here and it is cool indeed.. packing it into the next OS release.
Thanks again, Robert!I suddenly realise what this feature can do from drum tracks. For instance, have slightly different hihat sounds randomly triggered, or different snare sounds. Very cool…
Quote:I suddenly realise what this feature can do from drum tracks. For instance, have slightly different hihat sounds randomly triggered, or different snare sounds. Very cool…It is cool. I played with the beta today and I did exactly the above thing. But it is even cooler, because with sound sources like a drum kit with a limited range (such as my 808 and my DRM-1) you even have a built-in step probability: You just add notes to the chord pool and octave switch them out of the range of the reciever.
This is suuuper cool.However, this additional feature does not work for instruments with a normal (wide) range.
BUT: How about this: In the beta version every chord note can have one of three colours representing the three different octaves (you cycle through them). What about adding a muted state (a blinking LED) to the chord notes. Thus a muted chord note will not play at all, but it will still be in the chord pool. Result: By adding muted notes to a step chord in "random pool" mode, you will have created a variable probability effect! One note in the pool and two muted notes will be 33% chance that the one note will play etc.
Voila! What do you say?So betas are distributed by genoQs?
Anyway, I see what you mean, and I’ve been thinking about something like that as well. Would be nice! Maybe one more press on the note button could cycle to yet another state indicating a musical rest (silence), for instance with a blinking LED?
So that would mean a note press in the circle would do this:
1. On, octave #1.
2. On, octave #2.
3. On, octave #3.
4. On, musical rest (mute). (blinking LED).
5. Off. (LED off).I have no info about the new beta octave range feature, so I don’t know what LED colors are used.
The most current beta can now be downloaded in the service area.
Post edited by: admin, at: 2008/05/06 09:57
Quote:So that would mean a note press in the circle would do this:1. On, octave #1.
2. On, octave #2.
3. On, octave #3.
4. On, musical rest (mute). (blinking LED).
5. Off. (LED off).Yup, that is precisely what I meant.
I already used it on drums (as explained earlier) and it is really good for making that hit that only comes once in a while. Plus you may choose to have a random pick between several sounds that may come with the chosen probability.
I just read the section on Step events. Cool, will have to play with those. Anyway, it looks like the step’s AMT property is only used to control the effect of the step events on the step.
I’m proposing to use this same AMT value as a factor on the amount of randomness used to pick another note (or rest) from the pool. The higher the AMT value, the wilder the random pick. With a AMT value of 0, the base note will be picked in all cases.
I mentioned this before in this thread, but I now think I have a knob for this. I also wonder if the GRV property can be used to play a role…
Anyway, when using step events, the AMT and GRV properties should work as they’ve always done. Don’t change anything there. Having AMT used for both the random-from-pool feature *and* step events can have fun effects. For starters, it would mean that I can modulate the random-from-pool randomness by using AMT step events… I think, lol.
Fun?
Interesting thought. However the two effects of AMT in what you propose would be mixed, but at the same time semantically unrelated. Technically no problem, but probably not a good fit into the master model.
I do have an idea of how to add rests to the chord pool, will let you know how that goes as soon as I get my hands on a prototype.
Step GRV is already in use, but nothing against a refinement, as always
Yes, I’m aware of the semantic differences of the AMT knob in both cases. You are right, but I kinda liked the posibilities. Suddenly the AMT step event could be used to control the amount of note randomness when picking them out of the pool. But it’s a bit messy yes.
We need more attributes I guess. And a Shift button that allows a hole new range of attributes selected with the Shift-attribute combo key.
Good news on the rests in the chord pool! You managed to squeeze out a free bit from the note pitch data fields?
OK, need your help on this one.
Traditionally, to compose a chord on a step you hold down any of the chord buttons and enter your notes. Then you release the chord button and you are done. The chord block serves as a cardinality indicator (number of notes in the chord), but the buttons are not different in function. So far.
I have introduced a new twist, called chord size (working name). Chord size is different from chord cardinality in that it is independent and user definable between 1 and 7, you guessed it, using the chord block buttons.
When chord size and cardinality are the same you have the old model. Step plays a chord as expected.
Btw, size is shown in green, cardinality in red. When they overlap it’s orange, and we have the old model in place.When chord size differs from the cardinality.. what do you think should happen?
Chord size is nice in (and originates from) the random pool pick scenario because it easily gives you access to "rests", when size is greater than cardinality. But I have a feeling we can do a bit more with it in the cases where we don’t do pool picking.Now I need your thoughts..
Nice new approach to the chord data!
While it definitely can be used to insert some rests in the chord, it could also be used to set the polyphony of a step, also used for the random-pick-from-pool feature, and now for polyphony values larger than 1! I don’t think however it can do both. Let me see:
chord-size == note-count: normal behavior.
chord-size > note-count: inserts one or more rests.
chord-size < note-count: this could be the polyphony indicator as well as well as the trigger for the random-pick-from-pool feature, but… there’s no way to specify rests now, and I want those in.
I really, really think the random-pick-from-pool with polyphony larger than 1 (random chords!) will be super cool, and you just found a really nice way to specify this. So my suggestion would be:
1. Use the 5-step button press cycle to set a note as on-1, on-2, on-3, rest, and off in the note circle.
2. Use your new chord-size approach to set polyphony between 1 and 7. If polyphony is smaller than number of notes+rests defined in the chord, the random-from-chord-pool feature is enabled for that step, with indicated polyphony.
Btw, the links from the email notification to the replaced threads are all broken.
Post edited by: robert, at: 2008/05/09 08:18
Robert, one comment I had omitted on the 5 stage press cycle discussed earlier. The blink state (orange) is used already to identify the base pitch of the step, so it is not really free. But it is no issue.
Your suggestion is quite along the lines of what I think makes most sense. So I would only add to 2: "If polyphony (chord size) is greater than the number of notes defined in the chord, same rule applies, but add the appropriate number of rests to the pool to pick from." Seems consistent to me.
Finally, we still have the option to set the step to hard monophony using the mechanism already implemented in the beta. With this I think we cover all scenarios and open an entirely new cool playground.
- You must be logged in to reply to this topic.