Pure Data noob
Ok...... So I have been meaning to do this for a very long time......
I don't think it is the perfect "show_me_dollars" and so I will change it from time to time.
3rd attempt.........
show_me_dollars.zip
Here is a really terrifying screenshot, but I have also tried to explain it in words.
In many ways I think words ( below the screenshot) are easier to understand.
David.
Dollar $ variables in Pure Data patches.
A dollar variable is a thing that can be given a new value.
The new value can be a float or a symbol.
- If the Dollar variable is in an [object] box
A Pd patch can be saved and used inside another patch. We then call it an abstraction.... and it is just like a programming sub-routine.
If you want to use it many times then you have a problem, that they are all the same, so if you put an object [receive woof] they will all receive any message that you send with [send woof].
That might well be what you want to do.
But what if you want to send the message to only one of them?
You can give it an [inlet], but your patch will get messy, and what if your patch needs to make its own mind up about which abstraction it wants to send the message to, maybe depending on which midi note it received?
The solution is to give the abstraction arguments... some parameters that define it and make it different to the other copies.
For example [my_abstraction]
Let’s give it some arguments [my_abstraction 5 9 woof]
Inside the abstraction, as it is created (you open its parent patch) the dollar variables will be replaced. Wherever you see $1 written IN AN OBJECT it has been replaced by the number 5.
Number 5 because 5 is the first argument and has actually replaced the $1. You still see $1, but if you bang a [$1] object it will output 5.
[f $2] will output 9
[symbol $3] will output woof
So if you have an object [receive $1-$3] then it has now become [receive 5-woof]
And if you want to send it a message from outside, from another patch or abstraction, you will need to use [send 5-woof]
Every Pd patch, which remember includes your abstractions, also has a secret number. The number is unique and greater than 1000. As Pd opens each patch it gives it the number, increased by one from the last number it gave.
That number will replace $0 as the patch is created. You can find out what the number is by banging a [$0] object and connecting its output to a number box, or [print] object.
$0 can be used in any object as part of the name or the address, which means that a message cannot escape from the abstraction. A sub-patch like [pd my-subpatch] will be given the same number.
But from outside your abstraction you don’t know what it will be when the patch is created, so it is not useful. (A lie, you can find out, but as it can change every time you open your patch it is not worth the bother).
Use it to send messages within your patch [send $0-reset] to [receive $0-reset] for example, because the message is absolutely unique to its window, so you know it cannot interfere with other abstractions.
Use it also for objects like [delwrite~ $0-buffer 100] or for an array name [array $0-array] so that in each abstraction they have a different name and you will not have problems with their being "multiply defined"...... as each name can only exist once in your patch.
- If the Dollar $ variable is in a [message( box
Dollar $ variables are also replaced, but not as the patch is created (drawn by Pd as you open it).
Dollar zero $0 has no meaning in a message box. It will produce a zero if the message is banged, but that is it.
It is a mistake, a patching error, to put a $0 in a message box.
$1 $2 $3 $4 etc. in a message box are replaced by incoming atoms (individual floats or symbols or whatever) when they arrive. $1 will be replaced by the first atom in the list, $2 the second etc.
So if you have a message box [$1 $2 $3( ..... and you send into it a list [3 48 lala( .....then it will output 3 48 lala
That is not really very useful.
But it is actually very powerful.
Make a list in a message box........ [33 12 wav(
And bang it into a message box [open my-track$2-$1.$3( and you will get the output.........
open my-track12-33.wav
Which could be just the message that you want to send to [soundfiler]
P.S. If the first item in the incoming list is a symbol then it will be dropped causing errors.
You can fix that by making the message a list by passing it through the object [list].
Unfortunately only messages starting with a float are automatically recognised as lists.
libpd on mac: clarification requested on expected behavior of cpp sample
Thanks for those links Monetus. I'm pretty close with my existing setup and will first try to work with that when I have some more time. Some of the output from the samples/cpp/pdtest appears to be as expected.
However, from main.cpp
cout << endl << "BEGIN Patch Test" << endl;
// open patch
Patch patch = pd.openPatch("pd/test.pd", ".");
cout << patch << endl;
// close patch
pd.closePatch(patch);
cout << patch << endl;
// open patch again
patch = pd.openPatch(patch);
cout << patch << endl;
// process any received messages
//
// in a normal case (not a test like this), you would call this in
// your application main loop
pd.processFloat(1, inbuf, outbuf);
pd.receiveMessages();
cout << "FINISH Patch Test" << endl;
the response
BEGIN Patch Test
Patch: "pd/test.pd" $0: 1003 valid: 1
Patch: "pd/test.pd" $0: 0 valid: 0
Patch: "pd/test.pd" $0: 1005 valid: 1
PD: PATCH OPENED: 1003
print: 0
PD: PATCH OPENED: 1005
print: 0
FINISH Patch Test
seems right but no patch was opened and if I already opened that patch before running the executable, none of the print messages (called later in the code) showed up in the console of pd. I'll focus on this and try to repost to the forum when I have a better idea of what is going on.
Loading a pure data patch ( .pd file ) within a pure data patch ( .pd file )
HI!
Quick version:
My folder structure:
/mother-patch.pd ( main pure data patch first loaded and running... )
/patches/1/main.pd
/patches/2/main.pd
/patches/3/main.pd
...
How i could open /patches/1/main.pd triggered by some action in the mother-patch.pd?
How i could close /patches/1/main.pd triggered by some action in the mother-patch.pd?
Long read
I'm attempting to clone the Critter and Guitari organelle ( link ).
This instrument is basically a computer running libpd and running very cool pure data patches
You can read more about my project here ( link )
I have a mother pure data patch that it's first loaded when the device is on, this patch is doing some [send] and [receive] operations related to the knobs/keyboard/volume/led and it should be also managing the loading ( opening and closing ) of the child pure data patches ( mentioned above ). This child patches are receiving the actions from the mother patch.
If I open the mother patch and the child patches manually, everything works fine. But now I need to OPEN this CHILD PURE DATA patches with a object within the mother patch.
I've been testing [open] , for opening the main.pd of the child patches but it does not work.
I've been testing [pd] , for opening the main.pd of the child patches but it does not work.
I wouldn't like to modify the original organelle patches.
I wouldn't like to end up loading all the patches using [pd ...] and inserting a [switch] object inside every main.pd file in the patches in order to enable only the dsp of the desired patch.
It would be perfect If i could have a folder with all the patches and load them within the mother patch with some kind of object. And I would also want to be able to CLOSE the pure data patch and open another ( changing patches... )
Every little and big help woul be MUCH APRECIATED!
THANKS!!!!!!!
New to PD, need help with notes failing to turn off.
I've been working on my first major patch for the past few months. It's a synthesizer based heavily on the tutorial on flossmanuals.net. After finally creating all of the features I wanted I started to modify the patch to make the synthesizer polyphonic. The catch is that I want to control the patch using the Mad Catz Mustang midi guitar controller. This controller works perfectly fine with the polyphonic synth in the PD help browser as well as with other polyphonic synth patches I've found online, so I do not think the controller has any problem interacting with the [poly] object.. The problem is that when I use it with my patch, some notes fail to turn off. It seems to happen most often when I quickly slur from one note to another. I did not have this issue when using the monophonic version of my patch. The amplifier subpatch is definitely receiving noteoff messages, but for some reason, they do not cause the envelope to close.
I think part of the problem has to do with the way the controller sends messages. I use the controller in 'tap mode,' meaning a noteon is sent whenever a fret button is pressed and noteoffs are sent when fret buttons are released. However noteoffs are also sent whenever any fret button is pressed in order to turn off the "open string" (A note can be played without pressing a fret button by striking the string sensors, and the only way to turn it off is by playing a fretted note). This occurs whether or not the open string is playing and I think this may be messing with [poly]'s voice allocation. I'm tempted to just say that the controller can't be worked around, but since I know it works for other patches I'm going crazy trying to fix my patch.
I understand it would be hard to duplicate this behavior without having the controller, but as I said before it works like a dream with other patches. I have tried to imitate the polyphony of these patches as best as I can. I've tried disconnecting and reconnecting objects in every order imaginable and I've tried delaying on and off messages in case they were somehow arriving to the amplifier envelope out of order.
Attached is a simplified version of my polyph[full poly help.pd] onic patch. I'd really appreciate it if anyone could give it a quick look over just in case there's anything really obvious that I'm just missing.
Thanks so much and have a great day.
EDIT: Please ignore the errors about missing {receive~}s or {catch~}es. The {send~}s and {throw~}s are for some of the features that I removed from this version of the patch for simplicity's sake but I did not remove the {send~}s and {throw~}s.
Pure Data noob
We have all been there............
You have an abstract idea, and you are hard pressed to get ahead and build your patch!
But before you start....... you have to “know”...... at least......... that this.............
Is the same as this..........
Well........nearly. There is in fact much more in the second patch.
And although the second patch is not perfect (in fact there are many mistakes), it is much easier to work with (and easier to find those mistakes).
You can build the first patch in about 2 minutes using just two components (abstractions) of the second patch. An abstraction is a patch... like a subroutine... that you can use over and over again.
Why is this important?
Because at some point your patch will become very messy, and if you are unlucky then it will stop working. You will not be able to see the mistake in the giant cobweb that you have created...... and when you finally spot that mistake you will have to fix it in 200 different places!
It is quite likely that you will then delete important items or connections by accident and cause more problems...... and not finish your project on time.
If you have a new brainwave with the first patch then you will be eating your breakfast after a sleepless night with your patch. With the second you will be hearing the result within minutes.
Please study the attached patches for as long as you can remain interested. They are difficult if you really are a complete beginner. If you have more experience then you will of course understand a lot more...........
If none of that is even remotely understandable then you have missed out on the basics.
It is much easier to use a dishwasher if you know where to put the soap and that it needs mains electricity to work at all......... http://puredata.info/docs/manuals/pd/x2.htm
DO NOT read chapter 2.9 yet.
( I have tried to explain some of the workings, especially the use of $ variables within an abstraction. (PLEASE SEE THE POST "show_me_dollars" BELOW IF YOU DO NOT UNDERSTAND THE USE OF "$"))
Try to remember while you are working that there is almost always a better (and easier) way to build your patches. Look in “soundbox.pd” as well for some $ clues!
As your project progresses you might come back here again, having found that you are able to create abstractions of your own. You will then be amazed at your understanding of what I am sure looks very difficult at this first glance!
Please do glance........it will do you good in the long run......
Pd noob.zip
David.
Export to exe or dmg format
Eimer,
Pd and Pd-extended is free software and you may redistribute it, even in modified form, provided you follow the license terms (BSD and GPL).
If you are on OSX, it is very easy to create your own application with Pd-extended under the hood. Select menu-item 'file>>Make app from patch' or 'file>>Make app from folder'. What you get is a Pd-extended package with your patch as startup patch. The Pd window is minimized directly after startup, so at a first glance you don't notice it is Pd. But it is still fully functional with all Pd-extended libraries in it (120 MB!), and the possibility to edit patches and create new ones. With some extra tweaking, you can replace the Pd icon with an icon of your own make. The preferences file of this 'app' is within the app folder. If you included all necessary abstractions, and eventually your homebrew externals, you can distribute it as a stand alone app.
But probably you are not on OSX, otherwise you would have already seen this option. For Linux or Windows you could do something similar to the 'Make app' as described above, but do it by hand. You could write an executable tcl script to start Pd with your patch as startup patch, and eventually include other options in the script. (Pd uses Tk/tcl for graphics and other purposes, so it is included in every binary distribution of Pd-extended). The user can click that script to open your 'application'.
Disadvantages of distributing apps instead of patches are:
- you need to make separate distributions for every platform
- applications are large so you need ample download bandwidth on your server or host
- if Pd is obscured, you can't refer to Pd pages for support
All taken together, I see little advantage for distributing stand alone apps rather than Pd patches. If you want to make user-friendly distributions of your patches, you could organise them in a decent directory structure, where abstractions and other essential files are included in the search path by the [declare] object. For the user it is then a matter of installing a recent Pd(-extended) if they do not have it yet, and opening the main patch in your patches package. If all goes well, this is piece of cake, and on the other hand if they have troubles with soundcards etcetera, this is not something you could have prevented by supplying an app instead of a patch.
Katja
Open Kinect?
hey buscon,
here's a copy of a mail i sent a friend, and the corresponding patches.
you can see these patches being used here:
(original mail)
ok here's a simplified version of the patch i use. i've just modified the "mud" patch and haven't checked it all, so there are bugs and errors everywhere, but i guess you're just interested in the abs which receive and dispatch the data from kinect.
so the kinect is received by osceleton and what i get in pd is osc messages. basically it's x, y, and z coordinates for each point of the body. so you'll be interested in the patches "kinector" and "shooter".
KINECTOR:
- it translates the osc into data that the granular sampler "mud" can understand (0 to 1 linear).
- move the horizontal sliders to chose a user and a joint.
- toggle from "value" to "CC". in X Y and Z type a sending chanel number. in the granular patch, toggle from value to CC, so you can affect a receiving chanel number for each automatisable parameter.
- hit the "learn" buton and then cover with your body the area you wish to use. this sets minimums and maximum for each axis. if you want to calibrate the whole body at ounce first select "all_joints". hit the "learn" buton again to end calibration. body motion is now active.
- the toggle on the top right activates remote sound control for the "learn" function, for if you work alone. enable it, use the vertical slider to choose the gate for incoming volume. stand at your starting point, and clap or scream. calibrate, and clap again.
- if you toggle from "abs" to "rltv", instead of calibrating the movement of each joint in absolute space it will consider their relative distance to the torso joint. the advantage of this is one movement will have the same effect wherever you are positioned in the space.
- you save, open, and load presets as textfiles on your drive. you can save presets for the whole patch on the top right of the master patch.
SHOOTER:
- basically the same as kinector, but used for one-shots instead of continuous changes.
- chose a user, a joint, an axis, and a direction
- type a chanel cumber where it says CC
- in "time", type a time in miliseconds. everytime a joint passes a chosen point in space in a chosen direction, it will output a line from 0 to 1 in the chosen time.
- calibrate in the same way. you can use "all_joints" too bu there's a huge error somewhere so if you do first toggle to "value".
- same as kinector for the rest.
ok here you go. i don't know how much you know pd, so that's why i explained as much as i could. these patches are absolutely not clean, they're my first ideas since i got the kinect, and i'm working on more to have one tight patch in the end (including speed detection, movement prevision to compensate latency, etc ... ).
ok hope this helps.
if you have trouble using the "mud" patch let me know. if you are going to use the patch, please let me know and make sure you mention it's mine.
cheers
salut
gab
DJ/VJ scratching system
First my story: (you can skip down to END OF STORY if you want)
Ever since I saw Mike Relm go to town with a DVDJ, I've wanted a system where I could scratch and cue video. However, I haven't wanted to spend the $2500 for a DVDJ. As I was researching, I found a number of different systems. I am not a DJ by trade, so to get a system like Traktor or Serrato with their video modules plus turntables plus hardware plus a DJ mixer, soon everything gets really expensive. But in looking around, I found the Ms.Pinky system and after a little bit, I found a USB turntable on Woot for $60. So I bought it. It was marketed as a DJ turntable, but I knew that it wasn't really serious since it had a belt drive, but it came with a slip-pad and the USB connection meant that I wouldn't need a preamp. And so I spend the $100 on the Ms.Pinky vinyl plus software license (now only $80). This worked decently, but I had a lot of trouble really getting it totally on point. The relative mode worked well, but sometimes would skip if I scratched too vigorously. The absolute mode I couldn't get to work at all. After reading a little more, I came to the conclusion that my signal from vinyl to computer just wasn't strong enough, so I would need maybe a new needle or maybe a different turntable and I didn't really want to spend the money experimenting. I think that the Ms. Pinky system is probably a very good system with the right equipment, but I don't do this professionally, so I don't want to spend the loot on a system.
Earlier, before I bought Ms.Pinky (about two years ago), I had also looked around for a cheap MIDI USB DJ controller and not found one. Well, about a month ago, I saw the ION Discover DJ controller was on sale at Bed, Bath & Beyond for $50. They sold out before I could get one, but Vann's was selling it for $70, so I decided that that was good enough and bought one. I had planned to try to use it with Ms. Pinky since you can hook up MIDI controllers to it. But it turns out that you can hook up MIDI controllers to every control except the turntable, so that was a no go. If I had Max/MSP/Jitter, I could have changed that, but that's also way expensive. So, how should I scratch? My controller came with DJ'ing software and there's also some freeware, like Mixxx, but none of this has video support. So I look around and find Pure Data and GEM.
And I see lots of questions about scratching, how to do it. And there are even some tutorials and small patches out there, but as I look at them, none of them are quite what I'm looking for. The YouTube tutorial is really problematic because it's no good at all for scratching a song. It can create a scratching sound for a small sample, but it's taking the turntable's speed and using that as the position in the sample. If you did that with a longer song, it wouldn't even sound like a scratch. And then there are some which do work right, but none of them keep track of where you are in the playback. So, whenever you start scratching, you're starting from the beginning of the song or the middle.
So, I looked at all this and I said, "Hey, I can do this. I've got my spring break coming up. Looking at how easy PD looks and how much other good (if imperfect) work other people have done, I bet that I could build a good system for audio and video scratching within a week." And, I have.
END OF STORY
So that's what I'm presenting to you, my free audio and video scratching system in Pure Data (Pd-extended, really). I use the name DJ Lease Def, so it's the Lease Def DJ system. It's not quite perfect because it loads its samples into tables using soundfiler which means that it has a huge delay when you load a new file during which the whole thing goes silent. I am unhappy about this, but unsure how to fix it. Otherwise, it's pretty nifty. Anyway, rather than be one big patch, it relies on a system of patches which work with each other. Each of the different parts will come in several versions and you can choose which one you want to use and load up the different parts and they should work together correctly. Right now, for most of the parts there's only one version, but I'll be adding others later.
There's a more detailed instruction manual in the .zip file, but the summary is that you load:
the engine (only one version right now): loads the files, does the actual signal processing and playback
one control patch (three versions to choose from currently, two GUI versions and a MIDI version specific to the Ion Discover DJ): is used to do most of the controlling of the engine other than loading files such as scratching, fading, adjusting volume, etc.
zero or one cueing patch (one version, optional): manages the controls for jumping around to different points in songs
zero or one net patch (one version: video playback): does some sort of add-on. Will probably most commonly be used for video. The net patches have to run in a separate instance of Pd-extended and they listen for signals from the engine via local UDP packets. This is set-up this way because when the audio and video tried to run in the same instance, I would get periodic little pops, clicks, and other unsmoothnesses. The audio part renders 1000 times per second for maximum fidelity, but the video part only renders like 30 or 60 times per second. Pure Data is not quite smooth enough to handle this in a clever real-time multithreading manner to ensure that they both always get their time slices. But you put them in separate processes, it all works fine.
So, anyway, it's real scratching beginning exactly where you were in playing the song and when you stop scratching it picks up just where you left off, you can set and jump to cue points, and it does video which will follow right along with both the scratching and cuing. So I'm pretty proud of it. The downsides are that you have to separate the audio and video files, that the audio has to be uncompressed aiff or wav (and that loading a new file pauses everything for like 10 seconds), that for really smooth video when you're scratching or playing backwards you have to encode it with a codec with no inter-frame encoding such as MJPEG, which results in bigger video files (but the playback scratches perfectly as a result).
So anyway, check it out, let me know what you think. If you have any questions or feedback please share. If anyone wants to build control patches for other MIDI hardware, please do and share them with me. I'd be glad to include them in the download. The different patches communicate using send and receive with a standard set of symbols. I've included documentation about what the expected symbols and values are. Also, if anyone wants me to write patches for some piece of hardware that you have, if you can give me one, I'll be glad to do it.
Keith Irwin (DJ Lease Def)
What gives a sequencer its flavor?
A fantastically helpful reply. I had been making a patch that manufactures sequencer grids, which I might finish, though it's more of a cool idea than a practical necessity. While I was making it I did have many many thoughts about what would be cool, and I came up with a really big one, which I will share when I've finished a version of it. It presents one solution to the randomness/inhumanity problem.
Yeah I was considering using color changes with the toggles. I am pondering allowing for color-based velocity for each note, or maybe using an "accent" system that loudens accented notes by a certain modifiable percentage. I was also considering using structures to make a sequencer, but I don't want it to be really processor heavy. I might also purchase Max at some point to get another perspective on this live machine I'm building.
I do like the idea of weighting different sounds, timewise, maybe having some sort of changeable lead/delay param for each sequencer lane. Of course I am making pretty straightforward beat music, so anything weighted too heavily will have to be for texture and color rather than the core of the beat itself. I am also curious about the different ways to shuffle sequences, as with the MPC having a particularly pleasing shuffle algorithm. I guess I'm interested in rhythmic algorithms.
Anyway, I'm gonna just build as many different kinds of sequencers as I can think of, put them in a big patch, then have a MIDI router that allows me to output the sequences as note, CC, or other types of messages, then control various Pd and Logic synths from there. My true mission is to design a performance instrument that allows for tons of flexibility (independent sequence lengths, or being able to switch the output of a given sequence element), and with a very special twist. I can barely contain myself.
I think the ability to output any kind of message is one of the true strengths of Pd when compared with Logic. If I want to generate movement with a synth's params, I have to use that synth's internal mod matrix (if it has one), or I have to use automation which exists in a GUI element separated from any note information. I don't want to go digging into the nested windows of my sequencer program to be able to quickly program automation.
This conversation has me really excited. Thanks for the valuable input. And who are you, by the way?
D
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