Hi
I normally run things from a sequencer (muse) and this also holds for my current project. But I have a problem I'd like to solve with pd. I'd like to have an arpeggiator running in sync with muse, representing a few chords that's changing through the song.
My first thought was to have pd listen on two channels: all pressed notes on one channel represent the current chord. Midi notes on the other channel are only used as gate information. There should be a mode switch with up, down, up/down, random (did I forget some?).
Ok, I could go on and do my second external (since I would be able to write this up in C in no time), but I'm wondering:
Is there a similar wheel out there?
Would it be not-so-tricky to do as an abstraction? Newbie-me wouldn't
know how to a) hold onto a grab-bag of notes played on one channel and b) select them according to the selected mode. Which data structure would be nice to store/retrieve from in such a case (should dynamically grow/shrink)?
Hallo, Atte Andr? Jensen hat gesagt: // Atte Andr? Jensen wrote:
I normally run things from a sequencer (muse) and this also holds for my current project. But I have a problem I'd like to solve with pd. I'd like to have an arpeggiator running in sync with muse, representing a few chords that's changing through the song.
My first thought was to have pd listen on two channels: all pressed notes on one channel represent the current chord. Midi notes on the other channel are only used as gate information. There should be a mode switch with up, down, up/down, random (did I forget some?).
Ok, I could go on and do my second external (since I would be able to write this up in C in no time), but I'm wondering:
Is there a similar wheel out there?
Would it be not-so-tricky to do as an abstraction? Newbie-me wouldn't
know how to a) hold onto a grab-bag of notes played on one channel and b) select them according to the selected mode. Which data structure would be nice to store/retrieve from in such a case (should dynamically grow/shrink)?
Of course if you prefer to use C and just want to use Pd as a kind of library to make things like accessing soundcards or midi ports easier, just go on with it, this is a perfectly fine use of Pd.
Personally I wouldn't bother with an external for this, however, as it's very easy to do these things in Pd itself, and it may also be faster to adapt, because you don't need to write/compile/reload anything, just change the patch and be done with it.
To your specific problem: You should make yourself familiar with the table-object, with tabread and tabwrite, learn how to write counters in Pd (I posted a tutorial for this here several times), take a look at the random object, spigot also would be handy here, as could be the object "bag".
Also take a look at some of my list-abs abstractions to get some ideas of things that are possible with the list-object.
Then an approach you could try would be to make a 128-element table, write a 1 at every position, that has an active note, a 0 wherever there was a note off. Then everytime, a new note(off) comes in, update the table and dump the active notes into a second table, that you read out with tabread in whatever way you like: Either use a counter idiom to generate lookup indices or the random object etc.
Another possibility for selecting notes to play with the appregiator is implemented in the "sel-princ.pd" abstraction of the RTC-library. It has four lookup methods already built in, that are inspired by serialism: Rota, Series, Alea and Sequence.
Ciao
Frank Barknecht
On 12/09/2007, at 19.04, Frank Barknecht wrote:
Of course if you prefer to use C and just want to use Pd as a kind of library to make things like accessing soundcards or midi ports easier, just go on with it, this is a perfectly fine use of Pd.
I urge to say that i agree with this. Just to clarify. My initial
response wrt. this was only to let you (Atte) know of the (existing)
point of view regarding 'externals versus abstractions' as a follow
up to the question "did I reinvent the wheel?". I did that since you
said you were new to Pd, hence i assumed you didn't know of it
already. I didn't do it to imply a position in any direction.
Best, Steffen
On Wed, 2007-09-12 at 18:17 +0200, Atte André Jensen wrote:
Ok, I could go on and do my second external (since I would be able to write this up in C in no time), but I'm wondering:
- Is there a similar wheel out there?
there probably many ways to do it. i personally think, that the abstraction way is the more preferrable one, for reasons frank has already outlined.
- Would it be not-so-tricky to do as an abstraction? Newbie-me wouldn't
know how to a) hold onto a grab-bag of notes played on one channel
i believe, that for you as a c programmer it should also doable easily within pd as well. the main culprit is probably, that you might don't know already, which objects to use and also how to use certain design patterns in pd, that you might know from other languages. i tried to make a little sketch, how this could look like in pd (see attachment). i also used the bag metaphor, that you mentioned. when you see the patch, there is the bag on one hand and (i call them) "bag methods" on the other hand: [pd add_notes], [pd remove_notes] and [pd get_notes]. by using this design pattern, you can add easily as much methods to the bag as you want.
and b) select them according to the selected mode. Which data structure would be nice to store/retrieve from in such a case (should dynamically grow/shrink)?
the problem with my approach is, that the single notes are sorted by their noteon-time (or is this a feature? i don't know), whereas with the approach frank barknecht mentioned (the one using a table to store the state of each note) notes can easily sorted by their pitch, what probaby makes it easier to create different modes for your arpeggiator.
anyway, i think this task is a good example to get in contact with the logic of pd a bit. i encourage you to go on and ask the list again, if you need specific help.
roman
Roman Haefeli wrote:
anyway, i think this task is a good example to get in contact with the logic of pd a bit. i encourage you to go on and ask the list again, if you need specific help.
Thanks to both of you. I think I'll go for an abstraction, esp since I'm not really in a hurry here and I really, really want to learn pd.
I'll start toying with the entry points suggested by Frank, and see where I end up. And of course I'm probably gonna need more help from the list along the way :-)
Thanks again!
this is how i order notes in a table:
when a new note is input, read through the table until you reach either a 0, or a number higher than the new note. if you reach a zero, then put the new note in place of the zero. if you reach a higher note, then shift every remaining note 1 step forward in the table, and then put the new note in its place.
if a note is turned off, then read through the table until you find that note, and then move every remaining note 1 step back in the table. fill the end of the table with a zero.
usually you don't want more than about 10 notes for an arpeggiator, so the table reading will occur almost instantaniously.
also, for an arpeggiator, you really want to have an 'octave' function to really get some movement happening you can do it very simply by triggering a counter that goes up in 12's. so for just one octave, the counter always stays at zero, for two octaves it goes 0,12,0,12,..for 3 octaves 0,12,24,0,12,24..etc
a slider for the gate time is also good. make a slider from 0.001->1 where 1 keeps the note on for an entire beat, and 0.001 turns the note off almost immediately.
then, you want to have a radio controlling the speed of the arpeggiator...1/16 beats, 1/8 beats, 1/4 beats...etc
so that will give you a basic arp, which will sound ok in a 70's disco kind of way. make it into an abstraction.
the key to making it sound REALLY good is to use another arp or simple sequencer to modulate the settings of your first one.
if the speed is always set to 1/8 notes it's going to sound really rigid, so make another simple sequencer to rhythmically change the speed. wha-lah! now instead of metronomically boring 16th notes, you get 1/4 notes, 1/8th notes, and trills of 1/32 notes too.
and you can do the same thing to modulate the octave setting.
that's as far as i've got, and it sounds great. but i just had one other idea while typing this:
use another arpeggiator to send notes into the original arp.
also, arps are good to use in place of lfo's.
in conclusion. arps are awesome. you can build them with the most basic pd objects, and they sound wicked.
-
Atte André Jensen -
Frank Barknecht -
hard off -
Roman Haefeli -
Steffen