Problem with running different Sample rates in different instances using [Pd~]
Hi all,
I'm trying to run different instances of my main patch using the [pd~] object using 2 different sample rates.
Main patch runs at 48khz:
1st) [pd~ -ninsig 1 -noutsig 1 -sr 48000]
2nd) [pd~ -ninsig 1 -noutsig 1 -sr 12000] ---> this runs at 48 kHz
Unfortunately the sample rate of the main patch that contains the 2 [pd~] objects as shown above affect the sample rate of the sub instances.
So if my main patch containing the 2 [pd~] is running at 48kHz the 2 sub instances run at 48kHz overriding the one set to work at 12kHz and vice versa if the main patch runs at 12kHz then the sub instance that is set to run at 48kHz runs at 12kHz.
Main patch runs at 48khz:
1st) [pd~ -ninsig 1 -noutsig 1 -sr 48000]
2nd) [pd~ -ninsig 1 -noutsig 1 -sr 12000] ---> this runs at 48 kHz
Main patch runs at 12kHz
1st) [pd~ -ninsig 1 -noutsig 1 -sr 48000] ---> this runs at 12 kHz
2nd) [pd~ -ninsig 1 -noutsig 1 -sr 12000]
do you have any idea how I can get the 2 instances to run at different samplerate~ ?
Thank you in advance!
*[list item](Samplerate[Pd~]pd.pd link url)
new vanilla list sort
@ingox If you are looking for source code for any old extended externals they are all in https://sourceforge.net/projects/pure-data/files/pd-extended/0.43.4/Pd-extended_0.43.4-source.tar.bz2/download
Worth grabbing a copy while it remains available.
All the "makefile"s are included.
Useful for compiling externals for 64-bit (when they work).
I have seen the sort message almost hidden in a subpatch in 12-tut.pd in a tutorial on scalars here...... https://puredata.info/community/projects/convention04/lectures/tk-barknecht/tut.tgz
and it is mentioned (again... sort of.... with no explanation of the message call) as a function in Chapter 2.9.1 here...... http://puredata.info/docs/manuals/pd/x2.htm
and so it is also in Pd's \doc\1.manual\x2.htm
Zexy sort below. But it looks like the canvas sort is in g.graph.c.
There is an "if scalar sort" statement in there.
However g.graph.c has been disappeared from 0.49...... so......?
David.
.... sort.c.... (zexy)
In/*
* sort : sort a list of floats
*
* (c) 1999-2011 IOhannes m zmölnig, forum::für::umläute, institute of electronic music and acoustics (iem)
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation; either version 2
* of the License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License along
* with this program. If not, see <http://www.gnu.org/licenses/>.
*/
#include "zexy.h"
/* ------------------------- sort ------------------------------- */
/*
SHELL SORT: simple and easy
*/
static t_class *sort_class;
typedef struct _sort
{
t_object x_obj;
int bufsize;
t_float *buffer;
t_int *indices;
int ascending;
t_outlet*indexOut, *sortedOut;
} t_sort;
static void sort_dir(t_sort *x, t_float f)
{
x->ascending = (f < 0.f)?0:1;
}
static void sort_buffer(t_sort *x, int argc, t_atom *argv)
{
int n = argc;
t_float *buf;
t_atom *atombuf = argv;
if (argc != x->bufsize) {
if (x->buffer) freebytes(x->buffer, x->bufsize * sizeof(t_float));
if (x->indices)freebytes(x->indices, x->bufsize * sizeof(t_int));
x->bufsize = argc;
x->buffer = getbytes(x->bufsize * sizeof(t_float));
x->indices = getbytes(x->bufsize * sizeof(t_int));
}
buf = x->buffer;
while (n--){
*buf++ = atom_getfloat(atombuf++);
x->indices[n] = n;
}
}
static void sort_list(t_sort *x, t_symbol *s, int argc, t_atom *argv)
{
int step = argc, n;
t_atom *atombuf = (t_atom *)getbytes(sizeof(t_atom) * argc);
t_float *buf;
t_int *idx;
int i, loops = 1;
sort_buffer(x, argc, argv);
buf = x->buffer;
idx = x->indices;
while (step > 1) {
step = (step % 2)?(step+1)/2:step/2;
i = loops;
loops += 2;
while(i--) { /* there might be some optimization in here */
for (n=0; n<(argc-step); n++) {
if (buf[n] > buf[n+step]) {
t_int i_tmp = idx[n];
t_float f_tmp = buf[n];
buf[n] = buf[n+step];
buf[n+step] = f_tmp;
idx[n] = idx[n+step];
idx[n+step] = i_tmp;
}
}
}
}
if (x->ascending)
for (n = 0; n < argc; n++) SETFLOAT(&atombuf[n], idx[n]);
else
for (n = 0, i=argc-1; n < argc; n++, i--) SETFLOAT(&atombuf[n], idx[i]);
outlet_list(x->indexOut , gensym("list"), n, atombuf);
if (x->ascending)
for (n = 0; n < argc; n++) SETFLOAT(&atombuf[n], buf[n]);
else
for (n = 0, i=argc-1; n < argc; n++, i--) SETFLOAT(&atombuf[n], buf[i]);
outlet_list(x->sortedOut, gensym("list"), n, atombuf);
freebytes(atombuf, argc*sizeof(t_atom));
}
static void *sort_new(t_floatarg f)
{
t_sort *x = (t_sort *)pd_new(sort_class);
x->ascending = (f < 0.f)?0:1;
x->sortedOut=outlet_new(&x->x_obj, gensym("list"));
x->indexOut=outlet_new(&x->x_obj, gensym("list"));
x->bufsize = 0;
x->buffer = NULL;
inlet_new(&x->x_obj, &x->x_obj.ob_pd, gensym("float"), gensym("direction"));
return (x);
}
static void sort_help(t_sort*x)
{
post("\n%c sort\t\t:: sort a list of numbers", HEARTSYMBOL);
}
void sort_setup(void)
{
sort_class = class_new(gensym("sort"), (t_newmethod)sort_new,
0, sizeof(t_sort), 0, A_DEFFLOAT, 0);
class_addlist (sort_class, sort_list);
class_addmethod (sort_class, (t_method)sort_dir, gensym("direction"), A_DEFFLOAT, 0);
class_addmethod(sort_class, (t_method)sort_help, gensym("help"), A_NULL);
zexy_register("sort");
}
`
abl_link~ midi and audio sync setup
Hi Folks,
I thought I’d share this patch in the hopes that someone might be able to help improve upon it. I am by no means even semi competent with PD and jumped into this task without actually bothering to learn the basics of PD or RPi, but nevertheless here we are: maybe you can share a better implementation.
Mods/experienced folks, if I am sharing irrelevant/wrong/confusing info, mea culpa and please correct me.
I wanted to make a patch for PD in Raspberry Pi that would do 3 things:
- Get the abl_link~ temp data over wifi
- Create a midi clock output using a 5-pin midi adapter (I have one of the cheapo usb-to-midi cable things here)
-simultaneously create an audio pulse ‘clock’ output such as those used by volcas, Teenage Engineering Pocket operators, and the like (I am not sure if such an audio signal over a 3.5mm jack would be hot enough to be considered a CV pulse too, maybe you can help clear that up?)
As I say, after much struggles I have globbed something together that sort of does this.
A couple of things for newcomers like myself:
The abl_link~ object in the patch isn’t initially part of the standard pure data install as I write. I was able to use deken (ie the code that powers the ‘help/find externals’ bit of PD) to look for abl_link~. Search for it. At the time of writing there is a version for Arm7 devices like the Raspberry Pi 3 which was put together by the illustrious mzero with code from antlr. Go ahead and install the abl_link~ object. (Possibly you may have to uncheck the ‘hide foreign architectures’ box to get the arm7 version to show up. This is usually a safeguard to stop users from trying to install versions of externals that won’t work on their systems. So long as you see ‘arm7’ in the description it should hopefully be the one you want) PD will ask where you want to store the external, and I would just leave it at the default unless you have a special reason to do otherwise.
To get the patch to hook up to your preferred audio and midi outputs by default you may have to take certain steps. In my version of it I have deemed the built in audio and my cheapo USB midi output to be good enough for this task.
[As part of my troubleshooting process I ended up installing amidiauto which is linked to here: https://community.blokas.io/t/script-for-launching-pd-patch-with-midi-without-aconnect/1010/2
I undertook several installations in support of amidiauto which may be helping my system to see and link up my USB midi and PD, but nothing worked until I took the step in the following paragraph about startup flags in PD. (It may also be that I did not need to put in amidiauto at all. Maybe I’ll try that on another card to see if it simplifies the process. I’m saying you might want to try it without amidiauto first to see).]
Midi: - (ALSA is the onboard audio and midi solution that is part of Raspbian). To have PD use ALSA midi at the start I made the following setting in the preferences/startup dialog - within that window there is a section (initially blank) for startup flags. Here you can set instructions for PD to take note of when it starts up. I put in -alsamidi to tell it that alsamidi will be my preferred midi output. (I also took the step of going to file/preferences/midi settings, then ‘apply’ and ‘ok’ to confirm the Alsa midi ports that showed up. Then I went back to file/preferences/save all preferences. This seems to have (fingers crossed) saved the connection to my USB midi output.
Audio: I used the terminal and sudo raspi-config to set my audio out to the internal sound card (advanced options/audio/3.5mm jack). Since I had a fairly unused installation of PD I’d never asked it to do anything but work with the system defaults so getting audio out was fairly simple.
[nb I initially stuck this patch together on my Mac where everything worked pretty trouble free in terms of audio and midi selection]
About the patch. Obviously it is sort of horrible but there it is. It is a combination of stuff I cribbed from the demo example of abl_link~ in the example, and two example patches created by users NoDSP and jpg in this forum post https://forum.pdpatchrepo.info/topic/9545/generate-midi-clock-messages-from-pd/2
As well as some basic synthesis to make the bip bip noises I learned from LWMs youtube channel
https://www.youtube.com/channel/UCw5MbnaoDDuRPFsqaQpU9ig
Any and all errors and bad practice are mine alone.
The patch has some comments in it that doubtless expose my own lack of understanding more than anything. Undoubtedly many users can do a better job than I can.
Some observations on limitations/screwups of the patch:
-
If you disconnect from the stream for a bit, it will attempt to catch up. There will be a massive flurry of notes and/or audio bips as it plays all the intervening notes.
-
It doesn’t seem to be too fussy about where in the bar it is getting started (It will be "on" the beat but sometimes the ‘1’will be the ‘2’ etc. This is okay if I’m using internal sequencers from scratch (in the volca, say) but not if there is an existing pattern that I am trying to have come in 'on the 1'.
-
My solution to more detailed subdivision of bars was to make a big old list of numbers up to 32 so that abl_link~ can count up to more than 4. There’s probably a better solution for this. If you find that you need even more subdivisions because you are making some sort of inhumanly manic speed gabba, add even yet more numbers and connections.
I haven’t tested this much. And since it’s taken me the better part of 18 months to do this at all, I’m really not your guy to make it work any better. I’m posting here so that wiser souls can do a better job and maybe share what I think has the potential to be a useful midi sync tool.
I plan to revisit https://community.blokas.io/t/script-for-launching-pd-patch-with-midi-without-aconnect/1010/3
for some pointers on setting this up to launch the patch at startup to give me a small, portable midi Link sync device for 5-pin and audio-pulse clocked devices.
This is my first ever bit of quasi productive input to any technical community (mostly I just hang around asking dumb questions… So be kind and please use your giant brains to make it better) I look forward to spending some time learning the basics now. link-sync.pd
gem pix_film playback inconsistency issues
hellooooo
I am programming a simple patch (on mac osx) to link a temperature sensor data trigger via arduino to video playback with gem and having various issues getting the video to open and playback consistently. I've gotten the patch to work successfully occasionally by reseting the video file (through changing it to an .aiv file, running the patch without success, then changing the file back to .mov and running the patch with success) however this manual reset only works once and then i encounter the below issues when trying to run the patch again.
my first issue is that often the video file will open with (auto 1)--[pix_film] and only show a still frame image from the file without playing through, so i have to manually close [gemwin] instead of the third outlet bang from [pix_film] routing to [destroy], resetting [oneshot] to allow the bang to be triggered again, and resetting the toggle-- (auto 1)
my second issue is the most often the initial [trigger bang bang] that I've routed to simultaneously (create)--[gemwin], and toggle the (auto 1)--[pix_film file.mov] will instantly route to the finished [bang] on the third outlet of [pix_film] without opening [gemwin] or playing back the video at all, though the toggle will be activated until I manually turn it off.
since the patch works successfully sometimes for one round of -- opening window turning on the toggle-running playback-closing window and turning off the toggle-- i am wondering if there is a necessary message to reset [pix_film file.mov] in order to get the patch to work cyclically
any help would be greatly appreciated asap as im planning to utilize the patch live tonight
Abstraction list append and cold right inlet
I am getting a different result in my code when I run a patch as a an abstraction vs on its own. The issue seems to be with a list append object and the right cold inlet. The patch does the following:
- takes a number input
- pass the number input to the hot side of the list append
- if the number input is <= 127, pass 1 to the right cold side of list append else if it is 128 or greater pass 1 + 1 (2) to the right cold side list append.
- format the list in a message, print the message
- and also print the value of the data directly.
Here is the abstraction patch:
Here is the main patch:
When I run the main patch and enter 127 then 128 into the number atom I get the following output in the console:
first problem is the number out of range. Second problem is that the $2 value in the message is not the same as the value printed from "print result".
When I run the patch on its own and use the number atom in the patch for the value I get a different output in the console:
In this case the value of "print result" and the $2 value in the message are the same.
It seems there is a difference in the order of execution of the print statements and maybe there is also a difference in order of when the cold inlet on the list append gets updated.
Why is there a difference when run as an abstraction and how do I correct the number out of range error?
thanks for your help.
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.
Closing patches without Pd crashing, hopefully in an elegant way...
@whale-av Yes, the first patch closes fine, but the 2nd patch that closes it is crashing Pd.
I was thinking of another possibility. I could have 3 patches, and one just stays open the whole time, which would be the patch that closes all the other patches.
I would open my first patch. My 2nd patch would be the one that I would use to perform. Then when I want to change patches for a performance I open the 3rd patch that sends some kind of trigger that the 1st patch uses to close the 2nd patch, and then it closes the 3rd patch. The 1st patch just stays open till I shutdown.
It's a convoluted scheme, but that way I can avoid a patch needing to closes itself, which I think is what the problem is.
Closing patches without Pd crashing, hopefully in an elegant way...
Hi,
I have a headless Rpi setup using Pd .49.
I am trying to have everything automated, and one thing I'm trying to work out is that I want to close the patch I'm using before I open the next patch. I am doing this by sending internal Pd messages.
I used to quit Pd and re-open it, but due to problems I couldn't resolve after much time connecting my midi controller, I am going to try to just close my patch rather than quit and reopen Pd.
What I've worked out is that every patch will have a [r closepatch] object, and when I want to change patches I will open a patch that will send a bang from [s closepatch] , then it will close itself. I added several seconds of delay time to both patches, but this method always causes Pd to crash.
I am using this message to close a patch: [; pd-mypatch.pd menuclose 1(
My question: How can I close a patch from another patch, and then close the patch that closed the first one? Or is there a better way.
Even better, is there a way that I don't have to enter in the name of the main patch I want to close, like can I use some sort of variable, or send another internal message that will load the patch name into the patch closing message?
I am attatching what I have. First open "closetest1.pd" then "close_patch5.pd" If you connect the messages you can test them properly, but they always make Pd crash on my Rpi.
Thank You.
PdDroidParty MIDI in/out
@bamboomusic As I understand PdDroidParty it is for running a Pd patch on an android device.
You will need it to send OSC messages over the network to control a patch on your computer that deals with the midi.
Look to use [netsend -u -b] and [oscformat] on the Android patch (if they are included in the list of vanilla objects that will work with PdDroidParty)....... and [netreceive -u -b] and [oscparse] on your computer.
Then use the incoming OSC messages to control the midi objects on your computer.
You can just use [netsend] and [netreceive] and work with lists.... but OSC messages are more human readable.
The really simple solution is to buy a copy of the "TouchOSC" app for Android. Your Android interface will be much prettier and easier to build. It can send OSC and midi messages and has some ready-built templates for many DAWs. Once purchased (I think it is about $5-$6) you can put it on all your Android devices.......... https://hexler.net/software/touchosc-android
David.
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