Weird velocity behavior
@leonardopiuu said:
I began using plugdata a couple days ago and I'm making a simple mono synth
Mono synths are not simple! lol
MIDI's way of representing keyboard activity is not exactly convenient for mono use. So, I'm going to guess that the velocity and/or ADSR behavior is the result of a logic problem before reaching the ADSR.
Especially based on this comment: "BUT the velocity isn't sent out from the pack unless I press at least TWO keys at the same time..."
It's tricky. This was my solution, in the midimonoglide.pd abstraction:

Confused? Yeah. MIDI-to-mono logic is complicated enough that it will probably take you more than a couple of days of plugdata usage to really grasp it. There's no such thing as a "simple MIDI mono synth."
So I'd suggest to use either [else/mono] -- you already have ELSE lib, so, nothing else to install -- or my abstraction (which helps with mono note glide -- but you might not need that at this point.
Then, when you have properly cleaned up and filtered MIDI data, then the ADSR "should" be the easy part.
The ELSE way -- note here that every note-on sends out a non-zero velocity, so the envelope will retrigger repeatedly. I'm not crazy about that behavior, but it might be OK for your use case (and the patch is simpler).

The hjh way -- where it becomes possible to distinguish between sliding, non-retriggering notes and genuinely new notes. (The [noteglide] isn't strictly necessary -- but, IMO fingered portamento is the whole point of a MIDI monosynth
so I'm using it.)

Hope this helps -- and no worries. If you made this much progress in Pd in a couple days, to the point where you run into the not-at-all obvious subtleties of MIDI mono handling, that's pretty good.
hjh
Troubles compiling old version 0.43-4
Hi!
I'm digging up some old Pd patches that I wrote ages ago which no longer work on the current Pd version, and I need to run Pd 0.43 to compare some behaviors between the current version and that version.
Since I couldn't find any binaries at https://puredata.info/downloads/pure-data/releases/0.43.4, I downloaded the source code and I'm trying to compile it on Manjaro Linux.
Following the instructions in INSTALL.txt, it says there are two build systems, an "old" and a "new" one. I tried both and they fail with apparently very different issues.
With the "new" build system, when running make I get:
(...)
/usr/bin/ld: pd-s_audio_oss.o:(.bss+0x8): multiple definition of `sys_soundout'; pd-s_audio.o:(.bss+0x8): first defined here
/usr/bin/ld: pd-s_audio_oss.o:(.bss+0x0): multiple definition of `sys_soundin'; pd-s_audio.o:(.bss+0x0): first defined here
/usr/bin/ld: pd-s_audio_oss.o:(.bss+0x10): multiple definition of `sys_dacsr'; pd-s_audio.o:(.bss+0x10): first defined here
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:706: pd] Error 1
make[2]: Leaving directory '/home/teo/programmi/puredata/releases/043-4/pd-0.43-4/src'
make[1]: *** [Makefile:919: all-recursive] Error 1
make[1]: Leaving directory '/home/teo/programmi/puredata/releases/043-4/pd-0.43-4'
make: *** [Makefile:819: all] Error 2
With the "old" build system, when running ./configure I get:
(...)
checking tcl.h usability... yes
checking tcl.h presence... yes
checking for tcl.h... yes
checking for main in -ltcl85... no
checking for main in -ltcl8.5... no
checking for main in -ltcl84... no
checking for main in -ltcl8.4... no
checking for main in -ltcl8.3... no
checking for main in -ltcl8.2... no
checking for main in -ltcl8.0... no
no tcl library found
Any idea how to fix either?
Thanks
sub-patch with arguments?
@rph-r Ok, I will not tell you to use an abstraction.
A sub-patch is simply a window within a patch, and it takes its arguments from the patch that it is in.
So if you create [mypatch 1 2 3 4] then inside the patch, and also inside the sub-patch, $1 $2 $3 and $4 will be assigned the values 1 2 3 and 4 as the patch is opened.
If you need to put objects that are identical, but behave differently depending on arguments, within sub-patches then you need to give the main patch arguments.
A sub-patch cannot have its own arguments as it is actually an integral part of the main patch.
To achieve what you wish (I think I have understood) you will simply need to put your main patch within another patch (a container) and give your main patch the arguments.
If you then need to see and use guis that are in your main patch when you open the "container" patch then you can use the "graph on parent" from your main patch properties pop-up to show them in the container patch.
Or you can just open your main patch after opening the container patch.
But abstractions definitely make life easier, especially if you want to modify the current sub-patches for any reason.
David.
Max style Key Bindings
@flextUser just stumbled on my old tcl files with notes about adding menus and menu items so here they are if you still need them. Just the basic Tk menu commands work, I could have sworn pd required you to jump through some hoops.
add new menu:
.menubar insert <index> command -label <label> -command {<command>}
add new menu item to an existing menu:
.menubar.<menu> insert <index> command -label <label> -command {<command>}
Edit: And the popup menu.
set old_args [info args ::pdtk_canvas::create_popup]
set old_body [info body ::pdtk_canvas::create_popup]
rename ::pdtk_canvas::create_popup ""
append old_body {$popupid add command -label <label>}
proc ::pdtk_canvas::create_popup "$old_args" "$old_body"
unset old_args
unset old_body
If memory serves the roundabout way here was because there were some headaches with getting the proper $popupid value so exploiting the everything is a string nature of Tcl was the easier path. Not sure if that was because of my ignorance or actually the case.
Max style Key Bindings
@flextUser The menu is built as Pd loads so I think you must modify a couple of tcl files.
Like @oid I have played with it in he past, and here...... https://forum.pdpatchrepo.info/topic/9991/woof-a-new-window-menu-for-vanilla-tcl ...I added a drop down menu to the menu bar.
As you will see in that thread although the menu was added the tcl called did not work for all platforms.
I still don't know tk/tcl well enough to solve those issues.
It is also possible to create pop-up windows with pre-defined actions. Here is a sample..... popup plugin.zip
Again. I was just messing around without much knowledge, so some refinement would be useful.
I had just commented things that didn't work (thinking I might one day come back to them)... so a bit messy.
David.
pure data in multicore
@Spyros said:
- In the abstraction I replaced all the inlets to [receive] and [send] from the main, the [inlet~]s to [receive~] and [send~] from the main and the [outlet~] to [dac~]
Almost right. You convert the inlets to [receive] but in main you don't [send] to them, you send a message to the left-most inlet of [pd~] prefixed with the name of the receive. So if you originally had an inlet that accepted the message [go bears( and converted that to a [receive cheers], you would send the message [cheers go bears( to the left-most inlet of [pd~].
Similarly, you can't [send~] in main to a [receive~] in the subprocess patch. In the subprocess patch you replace all [inlet~] with [adc~] and in main you configure [pd~] ninsig to match the number of adc~ channels. Those channels become inlet~s on the [pd~] object itself.
- in the main I created [pd~] and I am sending a message <pd~ start pd~-button.pd> calling the abstraction button.pd. But I get an error: "pd~-button.pd: can't open" (in a separate instance of Pd). The weird thing is that when I go to help of [pd~] and click on the message <pd~ start pd~-subprocess.pd> I don't get the error when I copy and past the help in my main.pd I get an error: "pd~-subprocess.pd: can't open".
The message should contain the name of your abstraction, "button.pd" not "pd~-button.pd". In the help example, the name of the subprocess patch has that "pd~-" prefix, but that's just how they chose to name it.
- In the button abstraction I have more abstractions. Will they run in the new separate instance of Pd as well?
Yes, provided the Pd subprocess can find them. That's what failed in 2)--you copied the main patch in help but didn't move the subprocess patch to your local directory.
Here's another example you can study: two subprocesses.zip
grambilib~ - New ambisonics externals for Pd
thanks for the suggestion! I"ve never compiled anything before, but I gave it a shot...
I'm getting this error in PD after loading the 3 compiled objects (6 files: grambidec.pd_darwin, grambidec.pd_darwin.o, grambiman.pd_darwin, grambiman.pd_darwin.o, grambipan.pd_darwin, grambipan.pd_darwin.o):
load_object: Symbol "grambiman_setup" not found in "/Users/brianlindgren/Documents/Pd/externals/grambiman.pd_darwin"
Also make is generating a bunch of warnings:
++++ info: using Makefile.pdlibbuilder version 0.7.0
++++ info: using Pd API /Applications/Pd-0.54-1.app/Contents/Resources/src/m_pd.h
++++ info: making target all in lib grambidec~
++++ info: making grambidec.pd_darwin.o in lib grambidec~
cc -DPD -I "/Applications/Pd-0.54-1.app/Contents/Resources/src" -DUNIX -DMACOSX -I /sw/include -Wall -Wextra -Wshadow -Winline -Wstrict-aliasing -O3 -ffast-math -funroll-loops -fomit-frame-pointer -arch arm64 -mmacosx-version-min=10.6 -o grambidec.pd_darwin.o -c grambidec.c
grambidec.c:41:24: warning: unused variable 'x' [-Wunused-variable]
t_grambidec_tilde *x = (t_grambidec_tilde *)(w[1]);
^
grambidec.c:43:16: warning: unused variable 'APin2' [-Wunused-variable]
t_sample *APin2 = (t_sample *)(w[3]);
^
grambidec.c:44:16: warning: unused variable 'APin3' [-Wunused-variable]
t_sample *APin3 = (t_sample *)(w[4]);
^
grambidec.c:45:16: warning: unused variable 'APin4' [-Wunused-variable]
t_sample *APin4 = (t_sample *)(w[5]);
^
grambidec.c:69:24: warning: unused variable 'x' [-Wunused-variable]
t_grambidec_tilde *x = (t_grambidec_tilde *)(w[1]);
^
grambidec.c:78:23: warning: variable 'sample2' set but not used [-Wunused-but-set-variable]
t_sample sample1, sample2, sample3, sample4;
^
grambidec.c:78:41: warning: variable 'sample4' set but not used [-Wunused-but-set-variable]
t_sample sample1, sample2, sample3, sample4;
^
grambidec.c:102:24: warning: unused variable 'x' [-Wunused-variable]
t_grambidec_tilde *x = (t_grambidec_tilde *)(w[1]);
^
grambidec.c:113:41: warning: variable 'sample4' set but not used [-Wunused-but-set-variable]
t_sample sample1, sample2, sample3, sample4;
^
grambidec.c:143:24: warning: unused variable 'x' [-Wunused-variable]
t_grambidec_tilde *x = (t_grambidec_tilde *)(w[1]);
^
grambidec.c:185:24: warning: unused variable 'x' [-Wunused-variable]
t_grambidec_tilde *x = (t_grambidec_tilde *)(w[1]);
^
grambidec.c:228:24: warning: unused variable 'x' [-Wunused-variable]
t_grambidec_tilde *x = (t_grambidec_tilde *)(w[1]);
^
grambidec.c:282:24: warning: unused variable 'x' [-Wunused-variable]
t_grambidec_tilde *x = (t_grambidec_tilde *)(w[1]);
^
grambidec.c:351:37: warning: unused parameter 's' [-Wunused-parameter]
void *grambidec_tilde_new(t_symbol *s, int argc, t_atom *argv) //, t_floatarg test
^
grambidec.c:473:5: warning: performing pointer subtraction with a null pointer has undefined behavior [-Wnull-pointer-subtraction]
CLASS_MAINSIGNALIN(grambidec_tilde_class, t_grambidec_tilde, APf);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Applications/Pd-0.54-1.app/Contents/Resources/src/m_pd.h:529:59: note: expanded from macro 'CLASS_MAINSIGNALIN'
class_domainsignalin(c, (char *)(&((type *)0)->field) - (char *)0)
^ ~~~~~~~~~
15 warnings generated.
++++ info: linking objects in grambidec.pd_darwin for lib grambidec~
cc -undefined suppress -flat_namespace -bundle -arch arm64 -mmacosx-version-min=10.6 -o grambidec.pd_darwin grambidec.pd_darwin.o -lc
ld: warning: -undefined suppress is deprecated
ld: warning: -undefined suppress is deprecated
++++ info: making grambiman.pd_darwin.o in lib grambidec~
cc -DPD -I "/Applications/Pd-0.54-1.app/Contents/Resources/src" -DUNIX -DMACOSX -I /sw/include -Wall -Wextra -Wshadow -Winline -Wstrict-aliasing -O3 -ffast-math -funroll-loops -fomit-frame-pointer -arch arm64 -mmacosx-version-min=10.6 -o grambiman.pd_darwin.o -c grambiman.c
grambiman.c:64:24: warning: unused variable 'x' [-Wunused-variable]
t_grambiman_tilde *x = (t_grambiman_tilde *)(w[1]);
^
grambiman.c:139:24: warning: unused variable 'x' [-Wunused-variable]
t_grambiman_tilde *x = (t_grambiman_tilde *)(w[1]);
^
grambiman.c:226:24: warning: unused variable 'x' [-Wunused-variable]
t_grambiman_tilde *x = (t_grambiman_tilde *)(w[1]);
^
grambiman.c:252:32: warning: variable 'sample3' set but not used [-Wunused-but-set-variable]
t_sample sample1, sample2, sample3, sample4, sample10;
^
grambiman.c:306:24: warning: unused variable 'x' [-Wunused-variable]
t_grambiman_tilde *x = (t_grambiman_tilde *)(w[1]);
^
grambiman.c:370:37: warning: unused parameter 's' [-Wunused-parameter]
void *grambiman_tilde_new(t_symbol *s, int argc, t_atom *argv)
^
grambiman.c:436:5: warning: performing pointer subtraction with a null pointer has undefined behavior [-Wnull-pointer-subtraction]
CLASS_MAINSIGNALIN(grambiman_tilde_class, t_grambiman_tilde, APf);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Applications/Pd-0.54-1.app/Contents/Resources/src/m_pd.h:529:59: note: expanded from macro 'CLASS_MAINSIGNALIN'
class_domainsignalin(c, (char *)(&((type *)0)->field) - (char *)0)
^ ~~~~~~~~~
7 warnings generated.
++++ info: linking objects in grambiman.pd_darwin for lib grambidec~
cc -undefined suppress -flat_namespace -bundle -arch arm64 -mmacosx-version-min=10.6 -o grambiman.pd_darwin grambiman.pd_darwin.o -lc
ld: warning: -undefined suppress is deprecated
ld: warning: -undefined suppress is deprecated
++++ info: making grambipan.pd_darwin.o in lib grambidec~
cc -DPD -I "/Applications/Pd-0.54-1.app/Contents/Resources/src" -DUNIX -DMACOSX -I /sw/include -Wall -Wextra -Wshadow -Winline -Wstrict-aliasing -O3 -ffast-math -funroll-loops -fomit-frame-pointer -arch arm64 -mmacosx-version-min=10.6 -o grambipan.pd_darwin.o -c grambipan.c
grambipan.c:423:5: warning: performing pointer subtraction with a null pointer has undefined behavior [-Wnull-pointer-subtraction]
CLASS_MAINSIGNALIN(grambipan_tilde_class, t_grambipan_tilde, APf);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Applications/Pd-0.54-1.app/Contents/Resources/src/m_pd.h:529:59: note: expanded from macro 'CLASS_MAINSIGNALIN'
class_domainsignalin(c, (char *)(&((type *)0)->field) - (char *)0)
^ ~~~~~~~~~
1 warning generated.
++++ info: linking objects in grambipan.pd_darwin for lib grambidec~
cc -undefined suppress -flat_namespace -bundle -arch arm64 -mmacosx-version-min=10.6 -o grambipan.pd_darwin grambipan.pd_darwin.o -lc
ld: warning: -undefined suppress is deprecated
ld: warning: -undefined suppress is deprecated
++++info: target all in lib grambidec~ completed
This is my Makefile:
# Makefile for mylib
lib.name = grambidec~
class.sources = grambidec.c grambiman.c grambipan.c
datafiles = grambilib-help.pd readme.md
include Makefile.pdlibbuilder
Any suggestion? Thanks again!
Having issues with audio preferences and PD freezing up
Maybe 0.52-1 was running using Rosetta2 which is emulating Intel. A compiled external has to be for both the operating system and underlying architecture. Intel mac is x64, and M1/M2 is arm64/aarch64.
you can go look at these https://deken.puredata.info/ - you need ones that say 'Darwin-amd64-32' to run built for M1/M2 Macs .. But lets see the mac lore is they let you keep Rosetta for two versions of Mac OS, so for now you can stick with Rosetta2 (and that means install the Intel Mac version of PD and emulate it, at some point they will release like 13.3 or whatever theyre at (I'm still using mojave) and take it away but hopefully by then the externals you need will be compiled (or you can compile them yourself), otherwise stick with Big Sur or whatever you are on to keep Rosetta2 - I really haven't been paying attention.
timing events in pd
I am working on a piece that will turn on and off multiple motors at certain time based on certain variables.
What I'm trying to do is sequence like this:
sequence 1:
button is pressed
motor 1:
start at min 00: random pulse(ON time of 35 ms) every 7 - 10 sec
motor2:
start at min 01: random pulse(ON time of 35 ms) every 5 - 11 sec
motor3:
start at min 04: random pulse(ON time of 35 ms) every 3 - 13 sec
motor4:
start at min 06: random pulse(ON time of 35 ms) every 7 - 10 sec
motor5:
start at min 08: random pulse(ON time of 35 ms) every 5 - 12 sec
motor6:
start at min 10: random pulse(ON time of 35 ms) every 4 - 10 sec
all motors run
when button is pressed again (button count = 2):
sequence 2 starting:
motor 1:
continue random pulse(ON time of 35 ms) every 5 - 10 sec
stop after 01 min
motor 2: continue random pulse(ON time of 35 ms) every 3 - 12 sec
stop after 04 min
motor 3: continue random pulse(ON time of 35 ms) every 7 - 12 sec
stop after 10 min
motor 4: continue random pulse(ON time of 35 ms) every 3 - 8 sec
stop after 16 min
motor 5: continue random pulse(ON time of 35 ms) every 5 - 16 sec
stop after 18 min
motor 6: continue random pulse(ON time of 35 ms) every 7 - 10 sec
-- now only motor 6 is running >> button pressed>> last motor that running(motor 6) is stops.
sequence 3:
all motors pulsing together every 7 seconds for 2 minutes
after 2 minutes elapsed all motor stops.
how can I implements the above in PD?
how is possible to timing events without using metro rather something more accurate?
Thanks
Why doesn't pure data allow other audio and video applications to run in parallel in Linux?
Great!
I think you don't need the connection from Pd to the PulseAudio JACK Source. This is mixing Pd's output with the mic and then providing this to Pulse apps' mic input... I'm guessing this isn't what you meant.
system:capture --> PulseAudio JACK Source (mic available in Pulse apps, good)
system:capture --> Pure Data (mic available in Pd, good)
PulseAudio JACK Sink --> system:playback (can hear Pulse apps)
Pure Data --> system:playback (can hear Pd)
... at this point, you're finished -- you've got all the connections you really need. Anything extra is likely to be confusing later, so:
Pure Data --> PulseAudio JACK Source (Pulse apps can hear the mix of the mic and Pd, but cannot get the solo mic signal anymore, probably a bad idea except for Zoom meetings about Pd)
hjh

