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 .

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]

Hey guys, been lurking here a few weeks and posting for the first time. I'm trying to set up a patch such that I can run multiple instances of it at the same time without references getting mixed up. It's working out except for one detail: there is an array used for control in the main window of the patch I want to rename for every instance of the patch that I open. I'm trying to do this by calling it "g1" and then using

[loadbang]
|
[symbol $0-control]
|
[g1 rename $1(

to rename it as "1022-control" (or whatever) each time I open the patch. Thus if I open each instance of the patch one at a time, each array should have its own "10xx-control" name. This works EXCEPT: if I save the patch after opening and changing the array name, the array name gets saved as "1022-control" and the next time I open the patch I will get the obvious "error: no such array g1" error, as that array is stuck on the last $0 value before saving while everything else has updated!

Are there any workarounds for this, besides renaming the array to "g1" every time I change something with the patch and want to save? I also have an array I'm using as a buffer that gets renamed fine because it is in a

Thanks but all this did'nt slove the problem. When I try to install Pd with in a terminal with the command:
sudo dpkg -i Pd-0.39.2-extended-rc4-debian-stable-i386.deb
I get the following messages:

Selecting previously deselected package pd-extended.
(Reading database ... 90801 files and directories currently installed.)
Unpacking pd-extended (from Pd-0.39.2-extended-rc4-debian-stable-i386.deb) ...
dpkg: dependency problems prevent configuration of pd-extended:
pd-extended depends on libjack0.100.0-0; however:
Package libjack0.100.0-0 is not installed.
pd-extended depends on tcl8.4; however:
Package tcl8.4 is not installed.
pd-extended depends on tk8.4; however:
Package tk8.4 is not installed.
pd-extended depends on libflac7; however:
Package libflac7 is not installed.
pd-extended depends on imagemagick; however:
Package imagemagick is not installed.
pd-extended depends on libpng3; however:
Package libpng3 is not installed.
pd-extended depends on libmpeg1; however:
Package libmpeg1 is not installed.
pd-extended depends on libmpeg2-4; however:
Package libmpeg2-4 is not installed.
pd-extended depends on libmpeg3-1; however:
Package libmpeg3-1 is not installed.
pd-extended depends on libquicktime0; however:
Package libquicktime0 is not installed.
pd-extended depends on libimlib2; however:
Package libimlib2 is not installed.
pd-extended depends on libmagick++9c2a; however:
Package libmagick++9c2a is not installed.
dpkg: error processing pd-extended (--install):
dependency problems - leaving unconfigured
Errors were encountered while processing:
pd-extended
martin@martin-desktop:~/PD_extended$

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