What gives a sequencer its flavor?
i find, one of the good things to do, is to play round with a normal sequencer, and when you get a thought like "oh man, i wish i could just turn off the second half of the sequence every now and then", write that down, and then include that function in your own sequencer.
also, if you're designing a sequencer using pd's gui, those toggle buttons are absolute crap. but you can make them better with a bit of tweaking. instead of having just the little X show up in the middle of the toggle box, send a message like this:
[r $0-toggle-1(
|
- <- whatever number you put in here, is the colour
|
[color $1 $1 $1(
|
that way, the whole box gets turned on and off with a click. makes it much easier to see what's happening.
also, one of the biggest strengths with sequencing in pd is the ability to randomise, either randomly or intelligently. for example, if you are making a random drum pattern, then you probably want more notes to fall on 0,4,8, 12 than on 5, 7, 11....etc , so you build a patch that does that with weighted randoms and then you get reasonably cool sequences right off the bat that can be tweaked manually to work well.
just thinking of your idea about 'colouring' sequencers so that they lead or delay notes, and i think a cool way to do that would be to actually colour the individual sounds. so, for example, with a typical bass drum and hihat thing, you probably want the bass drum to be pretty steady, so you could assign it a colouration factor of 0.2 or something. but the hihat should be allowed to roam a bit, so maybe give it a 0.4.
but yeah, i think one of the best things about pd, is that you can program in all sorts of bends and tweaks that regular sequencers don't have. especially randomising stuff, makes it easy to try a heap of sequences very quickly. only problem i find with this type of method, is that it does tend to lead to the sounds becomign very erratic very quickly. with traditional sequencers, it takes a while to get all the notes in there, and you're more likely to just let it loop for a while and keep the same groove. but once you start getting into highspeed loop prototypes with randomization, you can switch between heaps of different sounds really quickly. this is really cool and definitely has advantages, but on the other hand, music is also something which has to come from the soul, so the jitterbug randomness does often mess things up too much. it's a bit of a balancing act, maybe. but if you can program the randomising stuff to work well and generally hit on good results, then that is better.
not sure if i answered much of the original question, but good to have a think about these things. cheers
What gives a sequencer its flavor?
I like Logic for many reasons. Sometimes I like that the sequencer is totally regular and orderly and normal. Sometimes I don't. I can do all kinds of awesome things with sequencers in Pd, like making sequencer patches with individual lanes that run at independent rates, for example. So I'm setting out to design a big improvisatory sequencer patch that includes drums, synths, samples, and loop-based recording. It will be totally awesome.
So designing sequencers and using vintage drum machine samples has got me thinking. I've read a handful of interviews with hiphop and techno producers who swear by hardware sequencers and drumboxes. They particularly tend to talk about the "feel" of particular sequencer or drumbox. I get that I won't really be able to replicate the metal frame of a LinnDrum in Pd, that there's something about the buttons, the knobs, the hardware-ness of these machines that encourages a certain style of composition unique to each box.
Given that I'm accepting certain limitations in GUI with any sequencer I design in Pd, how can I effectively create a sequencer that has a unique feel? And then, how can I create another one, with another unique feel? And on and on.
I also understand that certain sequencers, apart from the compositional elements of their front panels, also "color" their rhythmic outputs by leading or delaying the notes in a pleasing manner. Are there schematics somewhere that indicate how this occurs, per individual sequencer?
Also, an appeal to y'all imaginations. Who has cool ideas for sequencers? How can we flavor our sequencers uniquely so they aren't just spitting out Logic-esque, highly regulated streams of notes?
You guys are awesome!
D
PS - Best believe I am working on weirding up Logic's sequencer from within!
PdLive!
Thanks C.!
The amazing jazzdrumbox patch is from Andy, many of the patches here come from forums and posts from users.
The drummachine is actually mine so thanks
There is so many patch because it's a collection (even if some patches are very close to each others, maybe I'll make a selection later)
- the CTL patches deal with data ( for instance : midi seq, midi automations, or fiddle and bonk analyse to track signal and send midi notes and vel)
- Fx are fx
- S patches are instruments to be played with midi keyboard, or with ctl patches.
- z patches are used in other patches and can be used to create new ones.
Instruments patches are meant to be browsed with your classic browser, and I wanted them to be opened in a new pd window. But I guess I could add a menus to the main mixer patch to open synth, ctl patches and fx
The workflow 'should' be to first select your sounds/instruments select the audio bus then they are caught in the main window and that's were the patching begins with effects and controls. The main limitation is that I only have 5 audio buses for now, but I should add some more later on, a signal router may come in handy at that time .
Different ways of Implementing Delay Loops
Ta Toxonic - I'll take a look at the patch tonight. Good of you to take the time. Apologies if I've misunderstood though, but I think what you're describing is not quite what I mean: The pitch shift is separated out from the delay time - you're running a pitch shift effect into a separate delay line, which is not going to give the same effect. The delay time will not shorten as the pitch rises. I'll take a look at your patch tonight though as I may have misunderstood what you're getting at.
Maelstorm - thanks also. I understand why the pitch changes on a delay pedal. The pitchshifter patch was a bit of a red herring - though of course it's the same principle. The difference between what you're (both, I think) talking about and what I'm talking about is the way that the pitch changes.
Assuming a stable C tone playing into the delay:
With the standard simple PD delay set up, if you move the read point of a vd~ then you get a glissando as it accellerates, a constant pitch change as it moves at constant speed. So if you turn the knob to change the delay time in the middle of a tone you start with a constant pitch (C), then get a rise of pitch, then it levels out at a new pitch (as you turn then stop turning the knob),
_
___/
If you feed back into the delay, the glissando is repeated as the read speed changed while the write speed was constant:
_ _ _ _
/ |/ |/ |/ |
The effect I'm looking to emulate on the other hand is more akin to changing the speed of a phasor~ reading an array - the pitch change is not a blip, but a stable interval's transposition - eg: you turn the knob, the pitch of the repeats rise by a given interval and stays at that pitch as it repeats (now more quickly):
______
___/
If you play a constant C tone, then speed up the delay until it is a major third higher, you get a major third diad (until the delay dies away), rather than a C tone with a repeating squiggle overlaid.
The effect is the same as you get by speeding up a tape loop delay (though the pedal I'm trying to imitate is a digital delay) which is why I think the rate of the write and read heads are being increased by the same amount.
[edit, just tried to make this clearer and removed a couple of errors]
Audio/Video Granulizer
the sequencer's cool but it's a pain to label since it's so squished. the bottom left numbers just show what steps you're viewing, since you can only view 16 steps at a time, and you select which 16 steps you're viewing with the thin, long hradio in the middle. click around that and you'll see which sets of steps you're editing (1-16, 17-32, 33-48, etc.) up to 256 steps total. in the middle bottom, that number is where you set how many steps you want - it defaults to 16. the bottom right is the tempo, and the box next to that is just a counter to show what step you're on when playing. the small size 4 hradio to the right isn't currently used, but that's there so you can switch between 3 other sequences in the same sequencer.
i really didn't clean that patch up enough - i just realized two of the inlets set the total number of steps... the leftmost inlet sets the bpms and the rightmost is a toggle for start/stop. also sometimes when you save a sequence that's last value is a nonzero, if you extend the sequence after that it'll fill the new steps in with that value instead of zeros.
ultimately it's pretty multipurpose, what i usually do is run the outlet into a [select 0] just to throw out the 0's (since maybe you want to sequence negative values sometimes). the explanation in the patch just tells how it works with that specific sampler - to sequence it it takes 0-7 to trigger the 8 different lookup points, and it wraps so you can send 8 as 0, 9 as 1, etc (i like to do it like that so i can still throw out the zero's and not have to scale the input over a value in the sampler).
i forget who it was but someone in #dataflow inspired this sequencer - i had started with a small 16 step sequecner, then just made it bigger until it was a huge 128 number box GUI lagfest... discussing ways around it someone suggested that you use a sort of switching system so you can only VIEW 16 steps at a time, but can shuffle around a larger sequence. ultimately it took a while to figure out how to set up but it was super rewarding, the thing is super handy and has save/load! buyakasha!
A song from a few weeks ago
this is all live except for a minimal amount of sequencing... specifically, the chord progression that comes in after a few seconds, the sequencing of the breakbeats (they both share the same sequencing, i just crossfade them), and the sequencing of the granulizing on the breakbeats that come in later (which i also change a bit as it goes on). i'm basically alternating between two "lead" synths, controlled via oxygen8... they're just patches using osc~ and some wavetable distortion to mix the timbre up, lowpass it, then into a reverb... what i'll do is play on one synth, then crank up the reverb feedback on it and kill the input, then play with the other one, and vice versa... this is a method i never really played around with until i got into Pd, and i only started using it because of the lack of objects i had made really! it's a good way to get a nice big background sound, like a huge pad that looms over it...
the ending of this song drives me wild... when i recorded it, i had actually intended for the ending to be the first buildup (around 7-8 minutes), but when i played that melody on top of everything, i realized i had to do it again, so i did, and i'm SO glad i did... i basically distort the beat to white noise too, it's just this huge emotional moment, the epitome of where i want to go with Pd.
obi, the drums are a bit in the back, i need to work on some better distortion methods but i did throw a kick sample in there to help out the low end of the beat... this song was composed and performed entirely in Pd, but is more of a crazy patching mess than a complete .pd file... i've only implemented save/load for my sequencer as of late, so a lot of songs up until now i had no way to save them other than a .wav and a screenshot! (i usually save the huge performance patch and take a screenshot, because when i reopen the patch all the abstractions go to default values! but i'm starting to implement save/load in most patches, so hopefully soon i'll be able to have patches you can load right up and listen to)
anyways, glad you guys enjoyed! hopefully i do some more music soon (since i've been working mostly on more sound/gem patches, not really composing at all)
cheers! -ian
Announce: mmm-0.1.0-eden
hi forum.
we proudly announce the first public release of our compact composer
for pd, mmm.
grab it at http://netpd.org/mmm-0.1.0.zip
mmm is best described in it's faq, see below. don't expect too much
yet, there is still a lot to be done. comments, bugreports, cash, are
welcome.
have fun with it!
christopher charles & enrique erne
faq for mmm-0.1.0 - eden
what is mmm?
mmm is a pd patch collection aimed at providing a studiolike(?),
streamlined, dynamic interface for making synthetic music.
screenshots?
http://www.netpd.org/mmm.png
ymmv depending on your operating system. we put some effort in
detecting the operating system and setting the fontsize according to
it, but quirky xorg or dpi settings might screw things up again.
where can i get it?
we currently host the mmm at http://netpd.org/mmm-0.1.0.zip ,
alternatively, you can grab netpd, enter the chat, and if either of
the authors is online, download it directly through netpd and start
rocking.
what does "mmm" stand for?
mmm was originally just the working title, but we came to like it
somehow. the original meaning is "music making machine" but you can
substitute every m for whatever you want. so "massive multiplayer
music" is okay with us, too.
what is the inspiration?
having worked on/with the bagoftricks (lots inconsistently coloured
gop-patches to be connected freely) and netpd (lots of
inconsistent-looking windows to clutter up the screen), we came to
mock up an clean, dynamic interface in which modules don't bring their
own gop or open their own window, but log onto the interface that's
provided for them by the motherpatch. all modules sharing the same
interface made it easy for them to share the same sequencer and
arranger.
what are the dependencies?
mmm should work with pd-0.39 and zexy installed. iemlib is important
for many synth and effects patches, and there's even set of gem
modules you can chain if you want.
is it actually usable?
no. this 0.1.0 release is rather a tech demo and a taste of things to
potentially come. you can crunch some acid loops out of it already,
but don't sell your protools studio equipment to start working with
mmm on monday.
how does it work?
mmm's interface (mmmmain.pd) is divided into 3 parts: there is the
module/channel view, where you can chain up synths and effects on 8
different channels. select an empty field on a channel, and then use
the scrollbox on the left to select a patch and open it. when clicking
on a patch you loaded up in the module view, the 2nd view comes into
play: from there you control the patch's sliders on the left, right of
it is the stepsequencer for each of the slider (means everything is
sequencable!). yet you won't hear anything until you did the following
2 things: press play in the uppermost row of mmmmain, and set up the
arranger to play the stepsequence. the arranger is not module-based,
but controls all modules of a channel are grouped in the arranger. for
now, you can only select pattern 01 or nothing to play in the
arranger. so set up a loop for the first pattern (loopstart:0,
looplength:1) set the first field on the channel you got your patch on
in the arranger to p01 and start making some noise.
does it work online?
yes. mmm is compatible to netpd and will automatically log on to
netpd's server if you have the netpd chat open. you can also download
the whole mmm package through netpd. feel free to jam around the
world.
what's not working yet / what is planned?
as for now, there is no support for samples whatsoever, it isn't
planned to support them soon. further, there is no hard disk recorder
available yet, but it is planned. the arranger/sequencer combo is very
crippled at the moment, only supporting 1 16-step-pattern to choose
from and 1 page of 16 patterns in the arranger. this will change
rather soon. next there are plans for luxury editing functions,
especially in the sequencer like copy, paste, random pattern,
interpolation and so on. plans exist for full keyboard control, but
this will be worked on not too soon. the module roster is far from
being complete yet, more is to come.
can i save my stuff?
should be possible with the buttons above the channels. don't rely on
the result though, this is still 0.1.0
can i add my own modules?
modules are not to hard to write, but for now, the list of selectable
modules is hardcoded. look at all the 4m-* patches in the patches
folder to see how they are ticking. contact us for adding your patch
to the mmm or try to figure out yourself how it works
what's the license?
mmm is licensed under the gnu lgpl. if you think this is a too useful
product to be free of charge, please consider donating the amount of
money you would've paid for it (or the amount of money you got from
selling your protools equipment on monday) to a trust of your choice.
who are the authors?
mmm is developed by enrique erne (eni, swiss, pd{at}mild.ch) and
christopher charles (syntax_tn, germany, chr.m.charles{at}gmail.com).
we can be contacted via email, irc (#dataflow) or directly in the
netpd chat. several patches within mmm are based upon netpd versions
of them, check netpd for the original authors. mmm shares some of it's
netcode with netpd, by roman haefeli.
disclaimer.
we cannot give you any guarantees on using mmm, not even that you
have fun. it should be relatively harmless, but don't come crying to
us if mmm accidently hijacks your *mule and downloads david hasslehoff
recordings to your computer.
eofaq
Escher-esque chord progressions
I've been getting into writing patches that generate music all by themselves, using mathematical
rules that apply quite nicely to music theory. I've made a few rhythm patches that make nice cross
rhythms using metronome division and delays (with values derived from multiples of the master
metronome), and i'll post these too if anyone is interested.
In this thread I'm showing off my "Mauritz Escher like Chord progressions" patch.
Screenshot:
Mp3: http://responsible7.googlepages.com/zenpho_escher_pd.mp3
Patch: http://responsible7.googlepages.com/zenpho_escher.pd
First some basic music theory:
(skip this if you're comfortable with chords, 7ths, and inversions)
A major scale is constructed of 8 notes, with the "root" note doubled at the 8th note.
For the key of C major (all the "white" notes on a piano) the names and numbers of the notes in
the scale of C-major are:
Name, Number:
C, 1st (root)
D, 2nd
E, 3rd
F, 4th
G, 5th
A, 6th
B, 7th
C, 8th (remember the root is doubled at the octave)
A triad is constructed of the 1st, the 3rd, and the 5th notes in the scale.
A SEVENTH chord is constructed of a triad (notes 1,3 and 5) PLUS the 7th note in the
scale. So a C major 7th is note 1,3,5,7 or C,E,G,B.
Up until now we've been describing "standard" voicings of the chords, in other words, the notes
are played so that the root is the lowest pitched note, the 3rd is higher, the 5th is higher
still, and the 7th is the note just below the octave of the root.
At the risk of sounding redundant, "octave numbers" after the note name help clarify which octave
the note is to be played in. To play a C major 7th on the third octave, we would write:
C3,E3,G3,B3. To play it an octave higher we would write: C4,E4,G4,B4.
"Inversions" of chords re-order the pitches of the notes, but still play notes with the same
"name" as the 3rd, 5th, 7th etc. For example:
C3,E3,G3,B3 is a standard C major 7th...
...and G2,C3,E3,B3 is an inversion. All the notes are there (C,E,G,B) but they are in a different
order to the normal "Root, Third, Fifth, Seventh" arrangement. In this case, we say that "the
fifth is in the root".
Okay so now we know what a major 7th chord is. Lets deal with chord progressions.
Now imagine playing C3,E3,G3,B3 and removing the "root" (the C3) from the notes played,
we have a chord that reads "E3,G3,B3" - we were playing C major 7th and now we're playing E minor.
*THIS IS A VERY IMPORTANT STEP* Moving from C major 7 to E minor sounds "natrual" because the
notes that occour in C major 7 ALSO occour in the E minor.
Now lets make this E minor chord a 7th...
We've said before that a 7th chord can be constructed by playing the 1st, 3rd, and 5th notes, PLUS
the 7th note in the scale.
The scale of E minor (a flavour of minor) is:
Name, Number
E, 1st (root)
F#, 2nd
G, 3rd
E, 4th
B, 5th
C, 6th
D, 7th
E, 8th (octave)
The 7th note is "D" so we add the D note to our E minor triad to make E minor 7th.
E minor 7th is therefore: "E3,G3,B3,D4".
We can extend this E minor again, removing the root, working out the new scale for G major, adding
the 7th to make G major 7th, and again, and again, and again... but if we do - we keep moving
*UP IN PITCH* and spiral off the end of the keyboard.
HOW THE PATCH WORKS
Okay, so what my patch does is to take the idea of generating new 7th chords over and over,
but to play inversions of these chords so that the notes stay inside a single octave. If the
"root" note is in the 3rd octave, C3 for example. Then when I move to E minor, the D4 is
transposed to be a D3, to keep within this octave range.
Due to the fact that there are 12 semitones in an octave, and notes that fall outside the octave
range will wrap around to be an octave lower. The maths for generating the new chords basically
involves taking each note in the current major 7th chord and adding two semitones to each note in
turn.
Now our terminology could cause confusion here, because there are "notes in a scale" and "notes in a chord"... So I'm going to define some notation to show when i'm talking about the notes in a
chord.
For example:
A C major 7th has the notes C3,E3,G3,B3.
Note-1-in-the-chord is to be defined as chord_note_1.
Note-2-in-the-chord is defined as chord_note_2.
Note-3-in-the-chord is defined as chord_note_3.
Note-4-in-the-chord is defined as chord_note_4.
chord_note_1 has the pitch C3.
chord_note_2 has the pitch E3.
chord_note_3 has the pitch G3.
chord_note_4 has the pitch B3.
It is important to be clear about the idea of "pitch", "chord_notes" and "scale_notes" because
because chord_note_3 has the pitch "G3" and scale_note_3 of C major which is the pitch "E3".
Back to the procedure for generating new seventh chords.
We generate a major 7th to begin with.
C3,E3,G3,B3.
We add 2 semitones to chord_note_1 to get "D3", and we leave the other notes alone.
Our chord now reads: D3,E3,G3,B3.
Which is an "inversion" of E minor 7th.
This time we add 2 semitones to chord_note_2 to get "F#3", and we leave the other notes alone as
before.
Our chord now reads: D3,F#3,G3,B3
This is an inversion of G major 7th.
This time we add 2 semitones to chord_note_3 to get "A3", we leave the other notes.
Our chord now reads: D3,F#3,A3,B3
This is an inversion of B minor 7th.
This time we add 2 semitones to chord_note_4 to get C#4...
*BUT C#4 IS OUTSIDE THE OCTAVE 3! So we TRANSPOSE it down to C#3*
Our chord now reads: D#3,F#3,A3,C#3
This is an inversion of D major 7th.
After my patch modifies all 4 chord_notes, it moves back to chord_note_1, and adds another
2 semitones... over and over.
Eventually we get back to C major 7th again, but on the way we move through a variety of different
chords that evokes very interesting changes of moods.
Want to try playing with it?
Mp3: http://responsible7.googlepages.com/zenpho_escher_pd.mp3
Patch: http://responsible7.googlepages.com/zenpho_escher.pd
Favorite ways of doing GUI
i think one thing you should take into account when designing a GUI is something that will fit well ontop of the work you've already done. if your patch has a message handling structure already embedded in it (one that is sufficient to control all parameters of your patch), it would be very easy to employ either of the trends mentioned above.
if your patch has a set up where many sub-patches on a main canvas, perhaps the graph-on-parent method would work well.
another consideration is displaying information from your patch (not just controlling or changing it).
though i guess the main thing is usability. certain components and controls are going to fit your patch better than others. if your patch needs to be used in some type of performance, what features will make the patch easiest to use for the performer.
i do not know much about it other than it exists, but joseph sarlo at UCSD is working on GrlPd...sometype of layer for making GUI's for your patches. the link is [url=http://crca.ucsd.edu/~jsarlo/gripd/
]http://crca.ucsd.edu/~jsarlo/gripd/
i hope this helped some and perhaps it will stimulate some forum discussion.
Automation
personally, i wouldn't bother with saving the generated abstractions to a location on disk. i've revisited the patch i did a few months ago and what happens in my is that i have an abstraction that it set up to generate a subpatch on its own canvas (not the main patches canvas). so what happens is on the main patch, i create an instantiation of that abstraction with various creation arguments to make it unique. when that abstraction is instantiated, it goes through a sequence of events:
a. create the new subpatch on the abstraction's canvas. something like this:
[loadbang]
|
[symbol $1] ($1 is the name of the sub patch to be created)
| \
| [makefilename pd-%s] (you will need this symbol for referencing)
| |
[pack s s]
|
[ ; (
[ pd-abstraction.pd obj 83 500 pd-abstraction.pd $1; ( (create it)
[$2 vis 0 ( (hide it)
b. fill the subpatch with whatever it needs to function. e.g.
first you need to pack any parameters together that will govern how the subpatch is created. the only parameter you absolutely need is the name of the subpatch window prefixed by 'pd-'. you'll make this symbol as above with the makefilename object so it looks like pd-subpatch. other paremeters i used were a send/receive name, and one other numerical parameter. after you have your parameters packed, send them to a message like this ($1 is the window name, $2 and $3, are other parameters):
[pack s s f]
|
[ ; (
[pd-abstraction.pd vis 1, $1 vis 1 (
[$1 obj 10 10 r $2, obj 40 40 * $3; (
[$1 connect ....etc.... (
[ create and connect more objs (
[ $1 vis 0 (
[pd-abstraction.pd vis 0 (
note that i have included messages to show and hide windows. i don't know why it's necessary, but i ran into problems when the window wasn't visible. it probably has something to do with the coordinate system. another thing i did in my patch was before i sent this message, i ran a few messages to clear the contents of the subpatch just in case a subpatch with that name had already been created.
and that's about it. my actually patch was a little bit more complicated. i have simplified here for easier explanation. my patch had more complex naming conventions and more parameters were passed to the message box that created the contents of the new subpatch.
i hope this helps.