Table-using Abstraction can be used multiple times in one patch
@Maggie17 Sometimes it is easier with words........
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. - If the Dollar $ variable 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]
David.
Using two identical USB soundcards in Pure Data on Raspberry PI (raspbian stretch lite)
I needed a cheap way to get audio in/out of PD on RPI so I bought a couple of these tiny white USB soundcards with line out and mic input (less than a dollar each) as I'd read here that they work with RPI.
http://raspberrypimaker.com/cheap-quality-audio-raspberry-pi/
They work ( RPI1, model B ), and the output is decent, but there's an annoying high-pitched hum originating from the mic input that is probably due to the proximity of the ADC to the DAC on the unit.
I though I'd solve it by using one card for the mic input and another for the output.
As far as I understand, this should be possible using the -audiodevout options in the pd command line (or the gui settings). Neither of these have worked for me. Specifically, pd outputs from the same card, even though I specify the correct device number in =audiodev or -audiodevout. Both cards work well when used alone.
I'm guessing the problem is that pd sees the two devices (or at least refers to them) as identical. This is the output from pd -nogui -alsa -listdev
audio output devices:
- bcm2835 ALSA (hardware)
- bcm2835 ALSA (plug-in)
- USB PnP Sound Device (hardware)
- USB PnP Sound Device (plug-in)
- USB PnP Sound Device (hardware)
- USB PnP Sound Device (plug-in)
So even though one card is here listed as device 3-4, and the other as 5-6, pd always plays audio from the same card when given any of the numbers in -audiodev. / -audiodevout.
I'm very inexperienced with linux in general, but it seems that since alsa does give these two devices a unique name/number, pd. should be able to distinguish between them. This is the output from alsa -l
**** List of PLAYBACK Hardware Devices ****
card 0: ALSA [bcm2835 ALSA], device 0: bcm2835 ALSA [bcm2835 ALSA]
Subdevices: 7/7
Subdevice #0: subdevice #0
Subdevice #1: subdevice #1
Subdevice #2: subdevice #2
Subdevice #3: subdevice #3
Subdevice #4: subdevice #4
Subdevice #5: subdevice #5
Subdevice #6: subdevice #6
card 0: ALSA [bcm2835 ALSA], device 1: bcm2835 ALSA [bcm2835 IEC958/HDMI]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: Device [USB PnP Sound Device], device 0: USB Audio [USB Audio]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 2: Device_1 [USB PnP Sound Device], device 0: USB Audio [USB Audio]
Subdevices: 1/1
Subdevice #0: subdevice #0
Any advice would be greatly appreciated!
Audio Settings for multichannel with MOTU 828 mk3
Hi Matthieu,
I see your post is a little bit old but I'm experiencing the exact same problem now with my setup.
I'm using a Windows 7 machine with a MOTU 828x sound card connected via USB to the PC and Pd 0.48.1 vanilla.
Here what I've done:
- I've checked the "Use Stereo Pairs for Windows Audio" inside the "MOTU Audio Console";
- opened PD and selected "standard MMIO" as driver from the "Media" menù;
- now here's the list of outputs as it appears from the drop-down menu of "Media/Audio Setting.../Output device":
- MOTU Analog 3-4
- Loudspeakers (devide High ...
- MOTU Main-Out 1-2
- MOTU ADAT optical A 3-4
- Digital Output MOTU Audio
- MOTU ADAT optical A 1-2
- MOTU Analog 1-2
- MOTU ADAT optical A 7-8
- MOTU ADAT optical B 3-4
- MOTU Analog 7-8
- MOTU Analog 5-6
- Digital Output
- MOTU SPDIF 1-2
- MOTU ADAT optical B 1-2
- MOTU ADAT optical A 5-6
- MOTU Phones 1-2
As you see this list is pretty messed up and the names of logical consecutive output channels are not consequential. I would like to have 8 analog outputs from my MOTU so I selected the first item on the list (MOTU analog 3-4) then specified a total of 22 channels.
I'm obliged to set 22 as the total number of output channels because in my list MOTU Analog 5-6 are the last analog elements present. Because items in the list represent pairs of channels, this item corresponds to logical channel 21 and 22.
- Then I created the dac object this way:
[dac~ 13 14 1 2 21 22 19 20]
Here's an image
This way I'm able to hear sound on all analog outputs of the MOTU even if I'm experiencing variuous 'clicks' and a series of "resyncing audio" messages inside the PD console...
I confess, this method is the only way I'm able to make this setup work but it seems to me to be pretty messy and not intuitive at all.
What seems to be even worse is that analog audio outputs inside the device list seems to change their order at each computer restart, so every time I have to restart from scratch.
- Is there some easier solution to this problem?
- Maybe a preference file I can create for PD to load at each startup containing all these settings?
- or there may be a way to programmatically select correct "analog outputs" from the device list in my patch (even if string parsing doesn't seem to be so easy in PD to me).
- Would launching PD from console, maybe from an ad-hoc script, solve the problem?
Thank you so much for your support
M
foo_pd - Pure Data plugin for foobar2000
This is a spiritual successor to amPd. It's much more stable and has many more features than amPd:
-
reads/writes metadata to/from patches. This is done by storing the info in the form of comments, in a canvas called [pd meta] or [pd info]. If no such canvas exists, foobar will add it in the top left-hand corner of your patch.
-
comes with a Win32 Dialog UI element, containing sliders, toggles, buttons, and edit-text/button combos to send messages to your patch.
- foobar looks in your patch for a canvas called [pd mix] and uses the parameters of whatever sliders, bang objects, or toggles it finds there to give your UI controls similar functionality.
How playback works
- libpd sends a 1 to vol, then a bang to play.
- Generally this is where, in your patch, you have an [r play] hooked up to your metro, and an [r vol] connected to a [*~ ] before your output reaches [dac~].
- the length of the song is arbitrarily set by the user.
- This affects the trackbar's cursor visibility and ability to set a position.
- If the length is 0, there will be no trackbar cursor. Otherwise, the cursor, when moved, will send its position in seconds to pos. From there, it's up to your patch to take that information from [r pos] and work it into song events.
- The patch will not actually stop and move on to the next track until libpd receives a bang from [s stop].
How the mixer works
- all mixer controls go inside of [pd mix]
- horizontal and vertical sliders are turned into slider controls in the UI element
- labels assigned to sliders in the patch become labels for the UI element's slider controls. The same applies for send symbols.
- min and max values of sliders on the UI element work in integers only, so if you want a gradual shift from, say, 0 to 1, write "gradient" in the slider's receive symbol, and the slider's range will be broken down into roughly 200+ individual steps.
- there are currently 7 sliders in the UI element
- bang objects with no label become simple buttons in the UI
- their send symbols will be reflected in the button's name and they will send a bang when clicked.
- there are currently 3 buttons
- bang objects with a label assigned become message buttons
- these have an edit text field associated with them, where you can type out any message you want and send it to the destination.
- the bang's label is placed inside of the edit text field as a suggested message to send.
- pure data strips commas out of labels, so I'm using apostrophes to denote where commas should go. ex: do this' then this
- there are currently 2 message buttons, with the 'any' button being a potential 3rd.
- a bang object with a label written in the format dest : msg will be assigned to the 'any' button.
- the 'any' button has an editable destination field, giving you access to basically any receive symbol in your patch.
- also substitutes as a third normal message button, when the other two are already in use
- toggles become checkboxes
- each checkbox can have a label and send symbol assigned to it
- there are currently 4 checkboxes
- right-clicking a track shows the context menu entry Pd Player -> Load mixer.
- basically, you can load mixers of tracks not currently playing for some potentially interesting exchanges between patches. After loading the mixer, you still need to hit the Refresh button to show the changes.
foo_pd's copy of libpd.dll contains only the externals that I needed to run the example patches. If you want your own patches to work with foo_pd, you might need to make another build using MSYS2. If you're not sure which objects aren't instantiating, foobar's console prints all of pd's messages while audio is being processed. I'll also add more externals over time.
I'll be maintaining foo_pd at https://github.com/myQwil/foo_pd where you can also find the latest builds
foo_pd.zip
Last Updated: Feb 26, 2021 3:55pm EST
Ubuntu - Browsers and Puredata wont share audio output device. [SOLVED]
I found this solution and it worked
@sdaau_ml said:
Sorry to necro this thread, but I finally found out how to run PureData under Pulseaudio (which otherwise results with "ALSA output error (snd_pcm_open): Device or resource busy").
First of all, run:
pd -alsa -listdev
PD will start, and in the message window you'll see:
audio input devices: 1. HDA Intel PCH (hardware) 2. HDA Intel PCH (plug-in) audio output devices: 1. HDA Intel PCH (hardware) 2. HDA Intel PCH (plug-in) API number 1 no midi input devices found no midi output devices found
... or something similar.
Now, let's add the
pulse
ALSA device, and run-listdev
again:pd -alsa -alsaadd pulse -listdev
The output is now:
audio input devices: 1. HDA Intel PCH (hardware) 2. HDA Intel PCH (plug-in) 3. pulse audio output devices: 1. HDA Intel PCH (hardware) 2. HDA Intel PCH (plug-in) 3. pulse API number 1 no midi input devices found no midi output devices found
Notice, how from the original two ALSA devices, now we got three - where the third one is
pulse
!Now, the only thing we want to do, is that at startup (so, via the command line), we set
pd
to run in ALSA mode, we add thepulse
ALSA device, and then we choose the third (3) device (which is to say,pulse
) as the audio output device - and the command line argument for that inpd
is-audiooutdev
:pd -alsa -alsaadd pulse -audiooutdev 3 ~/Desktop/mypatch.pd
Yup, now when you enable DSP, the patch
mypatch.pd
should play through Pulseaudio, which means it will play (and mix) with other applications that may be playing sound at the time! You can confirm that the correct output device has been selected from the command line, if you open Media/Audio Settings... oncepd
starts:As the screenshot shows, now "Output device 1" is set to "pulse", which is what we needed.
Hope this helps someone!
EDIT: I had also done changes to
/etc/pulse/default.pa
as per https://wiki.archlinux.org/index.php/PulseAudio#ALSA.2Fdmix_without_grabbing_hardware_device beforehand, not sure whether that makes a difference or not (in any case, trying to adddmix
as a PD device and playing through it, doesn't work on my Ubuntu 14.04)
Sysex program dump with random zeros
Okay ;that's what I suspected you were doing. It is possible to use the MTP serial directly with linux and the mtpav driver, though this requires a machine with true hardware parallel port access (USB adapters won't cut it) and is limited to MIDI output only as the driver is a hack that was never finished. I used to run mine that way with a second USB MIDI interface connected to one or more of the MTP's unused routed MIDI outputs (there is, BTW still no way to connect the MTP USB version directly to a Linux system as it doesn't use a standard USB MIDI driver)
As far as the kernel is concerned, I've only ever used lowlatency or RT kernels for MIDI stuff. I don't know how a generic kernel would affect this problem but it's probably best avoided as they are not specifically built for multimedia.
Now read closely as this is where it becomes stupidly complicated.
First, make sure that the problem is internal to Pd. Your interfaces are probably not the issue (since Pd is only seeing the UM-1 driver I don't think the MTP even figures in here). However, the chosen MIDI API can get in the way, specifically in the case of the unfinished JACK MIDI. JACK MIDI presently can only pass SYSEX as short realtime messages. SYSEX data dumps will disappear if sent into the current JACK MIDI system. ALSA works OK. OSS probably too, but I have not tried it.
If that stuff is ruled out and you are still getting problems, it probably has to do with a set of longstanding bugs/oversights in the Pd MIDI stack that can affect the input, output, or both.
On the output side there is a sysex transmission bug which affects all versions of Pd Vanilla before 0.48. The patch that fixed Vanilla had already been applied to L20rk/PurrData for some time (years, I think). The output bug did not completely disable SYSEX output. What it did was to miss-format SYSEX in a way that can't be understood by most modern midi applications, including the standard USB MIDI driver software (SYSEX output from Pd is ignored and the driver/interface will not transmit anything). You would not notice this bug with a computer connected directly to an MTP because the MAC and Linux MTP drivers are programmed to pass raw unformatted MIDI.
If this is the problem and you have to use a pre-0.48 version of Vanilla it can be patched. See:
https://sourceforge.net/p/pure-data/bugs/1272/
On the MIDI input side of Pd we have 2 common problems. One is the (annoyingly unfinished but nevertheless implemented) input to output timestamping buffer that's supposed to provide sample-accurate MIDI at the output (if it was finished). This can be minimized with the proper startup flags (for a MIDI-only instance of Pd, -rt -noaudio -audiobuf 1 -sleepgrain 0.5 works for me) or completely defeated with a source code tweak to the s_midi.c file. This may not be the source of your particular problem as it usually only affects the time it takes to pass messages from input to output, but is worth mentioning as it can be very annoying regardless.
With SYSEX dumps it is more likely that the problem lies with the MIDI queue size. This is very common and I experienced it myself when trying to dump memory from a Korg Electribe Ea-1.. The current version of Pd limits the queue to a size of 512 (even worse it used to be 20) and any input larger than that will get truncated w/no error warning. There is not yet any way to change this with startup flags or user settings. This can only be "fixed" by a different tweak to s_midi.c and recompiling the app.
The attached text files are derived from the Pd-list and will show the specific mods that need to be made to s_midi.c.
Shell object, maybe bugged
Does any command work in the [shell] object that you are using? If you run something simple, like 'ls' or 'pwd' will it output the file list of the directory? If so, then there could likely be a formating issue with the text that you are sending to the object. The way that puredata handles sending certain symbols and characters through messages can sometimes throw a command askew when translating to bash. To make things harder, the front slash that is typically used as an escape symbol to send symbols as literals is not allowed in messages within pd... So if the [shell] object is functional, but your particular command just doesn't seem to want to work properly, then you can try the following:
1 - make use of objects that convert text in messages to and from symbols, like [makesymbol] [cyclone/tosymbol] [cyclone/fromsymbol] [s2l] [l2s] etc.
2 - try sending commands to shell via [text] or [coll].
3- when all else fails, or a script is just too complex or uses many odd characters, open a code editor like kate (or textmate on mac,) and type the code in there. Try running it in a terminal to make sure it works. Save the file, and then in terminal run
sudo chmod +x "/path/to/file/filename"
enter your password and now that file will be marked by the OS as executable. You can call it from the [shell] object by simply sending it the path to the file, or cd <path>; ./<filename>
If your script requires variables that change in pd, like $1 $2, then you can set that up in your script by defining variables and then sending those values as in separate messages. for example, in your code, you could start by defining a variable like
foo=0;
then in pd
[nbx]
|
[foo=$1(
|
[shell]
After you send the change in value to the variable, call the script again and it will output with the updated values.
In sticky situations in shell, this trick has saved the day for me many times. Hope that helps.
Pduino + Arduino Output to Pins
Unfortunately, snapshot~ doesn't seem to send data at a rate which enables clean signaling of arduino pins. When it comes to audio anything, I find that outputting signal is necessary, as outputting control values just cannot keep up with audio. If you are looking to make a square wave generator that is controllable from puredata, the best way that I have found to do this is by using a combination of arduino, a DAC chip and an op-amp chip. Also, you'll want to use at least a 12 bit DAC, such as mcp4921 or mcp4725, as 8 bit DAC lacks the ability to tune the output fine enough to stay in tune with standard tuning. For opamp choices, you can pretty much take your pick. They all do pretty much the same thing, though you will find that every opamp has it's own unique sound quality. I really love the gritty sound of the CA313. A very good and popular sound for opamp VCO is the tl072 or tl075. There are tons of schematics out there for how to configure a square wave vco with opamps. You would just modify the components to fit the output of your DAC.
Next, you would send your controller values from PD to the arduino and have some code in the ar'dweener to handle communicating with the DAC. You can then add all sorts of fun stuff to your board like digipots, opamp buffers, VCAs and so on to make envelopes, LFOs etc.
If you don't want to track down additional chips (usually ordered from china being the only way to find them, cheap though they tend to be,) but want to have square waves being output directly from the arduino, then you would still be better off having pd send control values to the arduino and then let the arduino handle the signal generation to it's pins. For this purpose, you may want to look at the tone library or the mozzi library. Teensy boards have some expanded audio capabilities as well, but teensy boards are a bit expensive for my taste, as you can get a freakin raspberry pi with a full linux operating system on it for a fraction of what it costs. Still, teensies are great and extremely handy for these types of applications if you dont mind dropping some extra money. I try to build everything to work on cheap arduino clones just for financial and practicality sake.
I have code and patches that I have written to control these types of circuits for many DACs and digipots with SPI and I2C protocalls... let me know if you'd like to check them out for some guidance.
plotting points on a curve using array...
HI,
this seems super obvious, but I can't figure it out.
I am trying to plot a curve on an array with certain points.
when x = 0, y = 38.89
when x = 6, y = 41.2
when x = 11, y = 43.65
I'm calling this array pitches1
in a message box i'm putting this
;pitches1 0 38.89 6 41.2 11 43.65
i also tried this
;pitches1 0 38.89, 6 41.2, 11 43.65
when using [tabread pitches1] and i input a 0 I get 38.89, a 1 outputs 6, a outputs 41.2, a 3 outputs 11, 4 outputs 43.65. Not the desired outcome.
what i want is 0 outputs 38.89, 6 outputs 41.2 and 11 outputs 43.65. and if I input a number like 3 it will be on the curve between 38.89 and 41.2. Does this make sense? So I want to plot a curve along several given points, but I don't want to input every value of x, only certain ones like 0, 6 and 11, and I want Pd to figure out the in between values.
Is this possible? And how would I format a message box to achieve this?
thank you!
Permutations, second part, can anybody get this patch to work?
@whale-av the technical side of what i imagined is now done, but the side concerning how it sounds still needs work, I want to create sound drawings that involve music without glissandi and music with glissandi, I want a fusion between these and its up to me for the composition, I love glissandi, and I want to fuse all parameters that I can think of in a sliding fashion, right now its the morphing timbre. the timbre part will be the most difficult, and it was my decision to work on it as the third parameter after pitch and intensity. As for me its common sense that for my favorite sounds, supposedly you can reach them by synthesizing and accumulating sine waves, so by this method I want to reach the sounds that i most love and morph in between them as much sounds as possible.
but this morphing timbre still needs work., the list works but on one part on the iannix score, the timbre curve was continual and the list was making jumps, is there a way for the list to "slide" from one combination to another without "jumping discretely", there will be time for jumping, but only when i want it and write it that way with vertical lines, with vertical lines in Iannix in a linear way I can jump from one place to another.