20 mode pole mixing and morphing filter. Updated
@oid said:
I am referring to it being made up from multiple objects instead of just one, analogy between transistors and integrated circuits.
Ok well, I was refering to the inherent phase shift that any digital filter has because of the discrete time and delay. No biggie.
Probably not control vs signal domain since they both have [mtof] on the cutoff so should be set to the exact same frequency. I am not talking about cancellation during the morph, as I said some transitions don't work, a resonance morph from 24db hp to 12db lp works but 24db hp to 18db lp results in the resonance results in the wrong phase after the morph, but a morph from 12db lp to 18db lp works just fine (don't recall if those actual transitions are the troublesome ones, just a random example). I suspect an error that can only be seen on the text level, order of operations (don't see anywhere this could be the issue) or an actual error which can not be seen in the patcher like the duplicate patch cable bug. I am fairly certain this just recently cropped up and the non-[lop~] filters did work but that might have just been an illusion caused by the mysterious 10 sample delay which had cropped up some how, I have no idea, hence starting over from scratch come weekend.
For resonance to work, there has to be a full 360 degree shift of the cut-off frequency while the other frequencies get cancelled/phased out. This works when you have 4 1 pole filters doing 45 degrees shift on the cutoff frequency each and then do negative (180 degree shift) feedback. But when you start mixing the different poles for the feedback you get all sorts of different phase distortions that wont create the magic self oscillation we love so much. Maybe try using the [filter-graph] abstractions from H10.measurement.pd to measure phase distortion on your resonance pole-mix and see what is going on.
As an aside, know of any suitable externals which is essentially [lop~] with signal rate? I looked some but only found more complex filters, would be nice to have that CPU savings which [lop~] provides but keep signal rate inputs. Or is the CPU difference primarily the signal rate cutoff? Seems too great to be just that.
I just ran a test on [rpole~] vs [lop~] (seppareately!)
Setting [rpole~] up like here, it works 'exactly* like [lop~]. They both spike at 30 CPU but stay at 20 most of the time. I think [rpole~] is as cheap as it gets with signal rate cut-off control. Of course, small differences add up when you have several instances.
Pd FLOSS Manual, what to do with it?
@60hz said:
So what I see is that pd-vanilla and his minimal gui with computer scientists oriented documentation is not suited for newcomers and artist but purr-data is. So that should make sense that flossmanuals should have a documentation about it.
It makes sense and we're saying Purr Data can have its own Floss manuals, but what are you talking about, a new entry or turning the current Floss Manuals into a Purr Data Manual?
By the way, the point of updating this Floss manuals to Vanilla is to make its documentation and itself more suited for newcomers, the solution to the exact problem you're raising it won't change if we don't do anything about it and if efforts to change it are rejected.
Folks, when I started this thread, I made no mention to Purr Data. Purr Data is something else. I get the confusion, I get the relation, it's not out of purpose to bring this up here, but I want to make things clear.
See, we're talking about a Manual, a so called "Pure Data" manual, which actually mixed the notion of Pd itself and Pd Extended (now dead) and sits around still as a "Pure Data" manual. While Pd itself has also its 'official' manual. That's all very confusing already, right? The point is then to fix this, work on the Pure Data documentation itself (it's all in the original post). Purr Data relates to Pd and Extended but it's a whole different animal. It has different configurations, interface, features and whatnot. More over, it has quite strong incompatibilities that people don't seem to bring up. When you have a so called Pure Data manual talking now about 'Purr Data' actually, things get even more confusing, we're adding more noise.
What's also confusing is the mixed notion of a 'Software Manual' and a 'Tutorial'. These are supposed to be distinct things. And tutorials are free to focus on different things. Floss seems to be a tutorial on how to do some stuff in Pd, not a 'real software manual' at all. Floss also seems to be good to talk about some externals for Pd. Cool... we could update it then and keep it mostly the same. The changes would be minimal. We'd have a good section on how to manage externals in Pd Vanilla theses days. That'd be great, right? How to configure, etc...
If you're saying, "but hey, I think most of the tutorial examples would work on Purr Data, as they already ship the externals we're talking about, cause they were originally based in Extended", fine! Cool! Great, we can see if what we have in the end perfectly suits being just implemented, opened, and used in Purr Data as well. I'm not talking about the configuration part and things like that, just running the patches...
If it's all fine we can just say "hey, the things you see here are also suited if you want to run Purr Data"
How about it?
Note: On the other side, I prefer using pd-ceammc libraries which are organized AND replace all pd-extended and more, so the best would be having Purr Data + ceammc lib and the peace would come back on earth...
They do not, by far, replace "all pd-extended", nope, sorry, not a fact. Where's ceammc's GEM replacement for instance?
And what are you suggesting with "Purr Data + ceammc lib"? A Floss manuals for both?
And are you talking about the ceammc library that you can install directly from vanilla and use it as part of vanilla or the 'Pd-ceammc' fork of Pd, that comes with the ceammc library and some more stuff?
Well... everything I said about "hey what about Purr Data?" applies here. And the fact is that Pd-ceammc, unlike Purr Data, is not a "whole different animal", it's pretty much just another 'race' of Pd. It is 100% compatible to Pd-Vanilla (unlike Purr Data). the changes are minimal. You can, for example, run Deken and install externals in Pd-ceammc.
If you don't want to bother using something else than Vanilla, you can install the ceammc library in Vanilla and just use most of what ceammc offers anyway. It's all compatible.
So any Pure Data Manual, Floss manual, tutorial, will work great for Pd-ceammc. And if we consider the fact that a Manual for Purr is needed (not a tutorial, a 'manual', a 'software manual') since it's just too different. That doesn't hold for Pd-ceammc.
And yeah, when I say Purr Data is highly incompatible, you can't run any of the GUI objects from Pd-ceammc in Purr Data. You can't run other GUIs from other libraries.
In fact, Purr Data doesn't even have all of the GUI externals from extended ported and running. Also, Purr Data misses updates from cyclone. Purr is also not doing a great job keeping up to the latest vanilla changes and has some changes of their own to vanilla things. So, unlike Extended and Vanilla, it's really hard tying them with a knot. Unfortunately, at least to me, the community is divided. There are independent developments. And it's hard to manage this, hence the talk about creating a whole new FLOSS for them if needed.
If Purr Data were in fact a reincarnation of Extended, fine. But that's not quite it. And here's something people don't really seem to be aware is that the best shot to have an updated external library that runs all extended patches is going to be "Vanilla + install externals yourself"
And there's also the fact that there are more libraries than just the extended libraries out there, and you can also get them into Vanilla. Like ceammc, like timbreid, like soundhack, like ELSE, like many many others that are just missing, not compatible or hard to get into Purr.
So, there's a way to have both Pd-ceamm + Purr Data when it comes to the externals - get them all for vanilla!
Sure, you'll miss the interface differences from Purr and maybe I don't know what. But that's it, and it needs to be clear what the choice is, there's also a sacrifice in giving up Vanilla.
Having lots of switches into Pd
@alexandros
This code sort of works with wip_multiple_PWM.pd
// merging works but pwm leds are choppy.
// number of elements in arrays need to
// match for() cycles in void setup and void loop
int pinsIn[2] = {2, 4};
int pinsAnalog[8] = {0, 1, 2, 3, 4, 5, 6, 7};
int pin = 0;
int val = 0;
int pinsOut[2] = {7, 12};
//TMP setup pwm:
// variables to hold pin numbers
int pwmLED1 = 3;
int pwmLED2 = 5;
int pwmLED3 = 6;
int pwmLED4 = 9;
int pwmLED5 = 10;
int pwmLED6 = 11;
// variables to hold pin states
int pwmLEDvalue1;
int pwmLEDvalue2;
int pwmLEDvalue3;
int pwmLEDvalue4;
int pwmLEDvalue5;
int pwmLEDvalue6;
//should this be omitted and use the a
// variable to hold and assemble incoming data
int temporary;
//END TMP pwm setup
void setup()
{
//set up a total of pins for digital input (has to match number of elements in array)
for(int i = 0; i < 2; i++)
pinMode(pinsIn[i], INPUT);
for (int i = 0; i < 2; i++) {
pinMode(pinsOut[i], OUTPUT);
digitalWrite(pinsOut[i], LOW);
}
//DEFAULT works with thermistors,
//INTERNAL with transitor thermostats
analogReference(DEFAULT);
pinMode(A0, INPUT_PULLUP);
pinMode(A1, INPUT_PULLUP);
pinMode(A2, INPUT_PULLUP);
pinMode(A3, INPUT_PULLUP);
pinMode(A4, INPUT_PULLUP);
pinMode(A5, INPUT_PULLUP);
pinMode(A6, INPUT);
pinMode(A7, INPUT);
//TMP test pwm setup:
pinMode(pwmLED1, OUTPUT);
pinMode(pwmLED2, OUTPUT);
pinMode(pwmLED3, OUTPUT);
pinMode(pwmLED4, OUTPUT);
pinMode(pwmLED5, OUTPUT);
pinMode(pwmLED6, OUTPUT);
Serial.begin(115200); // perhaps use a faster baud rate
}
void loop()
{
Serial.print("knobs"); // use "knobs" as a keyword so you can receive
// the knob values as a list with a [r knobs] in Pd
for(int i = 0; i < 8; i++){
unsigned int knob = analogRead (pinsAnalog[i]);
Serial.print(" "); // first print a white space to separate the "knob" keyword from the values
// and the values from each other
Serial.print(knob); // then print the actual knob value
}
Serial.println(); // finally print a newline character to denote end of data for keyword "knobs"
// the same technique applies to the switches too
// receive the switch values as a list with [r switches]
Serial.print("switches");
for(int i = 0; i < 2; i++) {
int switchVal = digitalRead(pinsIn[i]);
Serial.print(" ");
Serial.print(switchVal);
}
Serial.println();
//handle digital outputs
if (Serial.available()) {
static int temp;
byte in = Serial.read();
if (isDigit(in)) {
temp = temp * 10 + in - '0';
}
else if (in == 'p') {
pin = temp;
temp = 0;
}
else if (in == 'v') {
val = temp;
temp = 0;
digitalWrite(pinsOut[pin], val);
}
}
//TMP merge test PWMs:
while(Serial.available()){
byte inByte = Serial.read();
if((inByte >= '0') && (inByte <= '9'))
temporary = 10 * temporary + inByte - '0';
else{
if(inByte == 'p'){
pwmLEDvalue1 = temporary;
temporary = 0;
}
else if(inByte == 'q'){
pwmLEDvalue2 = temporary;
temporary = 0;
}
else if(inByte == 'r'){
pwmLEDvalue3 = temporary;
temporary = 0;
}
else if(inByte == 's'){
pwmLEDvalue4 = temporary;
temporary = 0;
}
else if(inByte == 't'){
pwmLEDvalue5 = temporary;
temporary = 0;
}
else if(inByte == 'u'){
pwmLEDvalue6 = temporary;
temporary = 0;
}
}
analogWrite(pwmLED1, pwmLEDvalue1);
analogWrite(pwmLED2, pwmLEDvalue2);
analogWrite(pwmLED3, pwmLEDvalue3);
analogWrite(pwmLED4, pwmLEDvalue4);
analogWrite(pwmLED5, pwmLEDvalue5);
analogWrite(pwmLED6, pwmLEDvalue6);
//digitalWrite(dspLED, dspLEDstate);
}
}
This is the code without PWM control. It works fine.
//number of elements in arrays need to match for() cycles in void setup
int pinsIn[4] = {6, 7, 8, 9};
int pinsAnalog[8] = {0, 1, 2, 3, 4, 5, 6, 7};
int pin = 0;
int val = 0;
int pinsOut[4] = {2, 3, 4, 5};
void setup()
{
//set up a total of pins for digital input (has to match number of elements in array)
for(int i = 0; i < 4; i++)
pinMode(pinsIn[i], INPUT);
for (int i = 0; i < 4; i++) {
pinMode(pinsOut[i], OUTPUT);
digitalWrite(pinsOut[i], LOW);
}
//DEFAULT works with thermistors,
//INTERNAL with transitor thermostats
// ELLER var det tvartom???
analogReference(DEFAULT);
pinMode(A0, INPUT_PULLUP);
pinMode(A1, INPUT_PULLUP);
pinMode(A2, INPUT_PULLUP);
pinMode(A3, INPUT_PULLUP);
pinMode(A4, INPUT_PULLUP);
pinMode(A5, INPUT_PULLUP);
pinMode(A6, INPUT);
pinMode(A7, INPUT);
Serial.begin(115200); // perhaps use a faster baud rate
}
void loop()
{
Serial.print("knobs"); // use "knobs" as a keyword so you can receive
// the knob values as a list with a [r knobs] in Pd
for(int i = 0; i < 8; i++){
unsigned int knob = analogRead (pinsAnalog[i]);
Serial.print(" "); // first print a white space to separate the "knob" keyword from the values
// and the values from each other
Serial.print(knob); // then print the actual knob value
}
Serial.println(); // finally print a newline character to denote end of data for keyword "knobs"
// the same technique applies to the switches too
// receive the switch values as a list with [r switches]
Serial.print("switches");
for(int i = 0; i < 4; i++) {
int switchVal = digitalRead(pinsIn[i]);
Serial.print(" ");
Serial.print(switchVal);
}
Serial.println();
//handle digital outputs
if (Serial.available()) {
static int temp;
byte in = Serial.read();
if (isDigit(in)) {
temp = temp * 10 + in - '0';
}
else if (in == 'p') {
pin = temp;
temp = 0;
}
else if (in == 'v') {
val = temp;
temp = 0;
digitalWrite(pinsOut[pin], val);
}
}
}
and here is the code from tutorial5 from Arduino for Pd'ers. It goes with arduinoforpdrs_tut5.pd
// variables to hold pin numbers
int pwmLED = 9;
int dspLED = 2;
// variables to hold pin states
int pwmLEDvalue;
int dspLEDstate;
//variable to hold and assemble incoming data
int temporary;
void setup()
{
pinMode(pwmLED, OUTPUT);
pinMode(dspLED, OUTPUT);
Serial.begin(9600);
}
void loop()
{
while(Serial.available()){
byte inByte = Serial.read();
if((inByte >= '0') && (inByte <= '9'))
temporary = 10 * temporary + inByte - '0';
else{
if(inByte == 'p'){
pwmLEDvalue = temporary;
temporary = 0;
}
else if(inByte == 'd'){
dspLEDstate = temporary;
temporary = 0;
}
}
analogWrite(pwmLED, pwmLEDvalue);
digitalWrite(dspLED, dspLEDstate);
}
}
I am aiming at using same type of array handling as for the digital outs.
Thanks a lot
Having lots of switches into Pd
I would suggest to not mix the analog values with the digital ones. The first code could be changed to the following (using Serial.print() with the [serial_print] abstraction):
void setup()
{
for(int i = 2; i < 14; i++)
pinMode(i, INPUT);
Serial.begin(115200); // perhaps use a faster baud rate
}
void loop()
{
Serial.print("knobs"); // use "knobs" as a keyword so you can receive
// the knob values as a list with a [r knobs] in Pd
for(int i = 0; i < 6; i++){
unsigned int knob = analogRead (i);
Serial.print(" "); // first print a white space to separate the "knob" keyword from the values
// and the values from each other
Serial.print(knob); // then print the actual knob value
}
Serial.println(); // finally print a newline character to denote end of data for keyword "knobs"
// the same technique applies to the switches too
// receive the switch values as a list with [r switches]
Serial.print("switches");
for(int i = 2; i < 14; i++) {
int switchVal = digitalRead(i);
Serial.print(" ");
Serial.print(switchVal);
}
Serial.println();
}
As for writing to several outputs you need to set which output you want to write to and then the value you want to write. Here's an example that writes to several different digital outputs:
int pin = 0;
int val = 0;
// some random pins
int pins[4] = {3, 4, 5, 6];
void setup() {
for (int i = 0; i < 4; i++) {
pinMode(pins[i], OUTPUT);
digitalWrite(pins[i], LOW);
}
Serial.begin(115200);
}
void loop() {
if (Serial.available()) {
static int temp;
byte in = Serial.read();
if (isDigit(in)) {
temp = temp * 10 + in - '0';
}
else if (in == 'p') {
pin = temp;
temp = 0;
}
else if (in == 'v') {
val = temp;
temp = 0;
digitalWrite(pins[pin], val);
}
}
With the code above you can send messages like this one print $1p$2v
in Pd to the [comport] object. $1 is the number of the pin you want to light up starting from 0 and incrementing by 1 (so the first pin used which is pin 3 in the Arduino code would be 0 in the Pd patch), and $2 is the value, 0 or 1.
Note though that in the first code (and the code you posted), you're using all digital pins as inputs so there's no pin left to use as output. If you want to combine these two chunks of code you'll have to use less pins as inputs and leave some to be used as outputs.
Fresh Pd 0.50.2 install comes with broken libs and deken installs broken libs
@ddw_music said:
One way that this could be improved:
- Pd could recommend externals be placed under a specific location. (Actually, here, you could follow SuperCollider's lead and have a system-wide location and a user-specific location.)
well, pd does now prompt/recommend a directory for installing externals (e.g. ~/Documents/Pd). It just so happens that the path isn't in the static paths. It was better when there were just 2 standard library locations: 1 for system-wide libraries and 1 for user-specific libraries (e.g. /Library/Pd and ~/Library/Pd on osx). This is still technically the case, they're just not the directories that pd prompts the user to install externals to. (though they are installed there by default) http://msp.ucsd.edu/Pd_documentation/x4.htm#s2.1
imo prompting the user to create ~/Documents/Pd and install externals there is a mistake
- Per patch file, keep a list of which locations have provided externals or abstractions.
the declare help file does say "WARNING: as of version 0.47, "declare -path" and "declare -stdpath" inside abstractions take effect only within those abstractions. If Pd's compatibility version is set to 0.46 or earlier the old (buggy) behavior takes effect."
perhaps this could be extended to libraries too
- If there is a binary library in the access path, load it automatically. Do not make the user distinguish between lib and path.
I agree that if someone specifies "-lib" it should work for multi-object, abstraction, and single-object libraries. However there should be cases for adding to a path without it being a library imo.
maybe the solution is a general "import" object for libraries like extended used to have, since [declare]
seems to be designed to refer to specific binaries and paths without any further method of abstraction.
- If it's the first time this subdirectory provided an object to this patch file, print a message in the console (help the user not overlook the dependency).
I don't think this is a good idea. It would clog up the console. maybe there could be some kind of helper object or something in [pdcontrol]
or [declare]
that gets a list of all of the library or external dependencies of a patch when the user needs them. (or maybe some external would be better).
- Have a menu option to print a list of dependencies. (If the list of external subdirectories is saved in the patch, this is easy.)
The whole idea of using [declare]
is to be able to understand a patch's dependencies just by opening it. Of course when people develop with libraries loaded into their startup path instead of using [declare]
or [libraryname/objectname]
, that doesn't work. But if people actually used [import]
or something instead this would be unnecessary
For me, the sticking points are that the search is non-recursive (this design decision, frankly, baffles me, I could not disagree with it more strongly) and that the user is expected to know which external packs provide a single-binary library.
I think it's good that libraries aren't searched recursively. This allows the maintainer/developer full control of loading resources, and doesn't waste time searching potentially large non-object resource directories in a library every time an object is loaded.
[declare] vs help browser
As a further test -- I hacked ./tcl/helpbrowser.tcl to print to stdout some progress messages while building the help browser directory list. (Doing this in Linux -- I haven't set up the Windows machine to build Pd from source.)
To my surprise, I found that the Externals Install Directory is part of $::sys_staticpath (in Linux).
Each entry in $::sys_staticpath is globbed for any subdirectories -- so this is how it's finding Gem, cyclone, zexy etc.
staticpath add search /home/dlm/pd-externals/Gem
staticpath add search /home/dlm/pd-externals/freeverb~
staticpath add search /home/dlm/pd-externals/zexy
... etc.
A little bit later, it checks $::sys_searchpath -- this comes from preferences. These entries are not globbed for subdirectories.
searchpath add search /home/dlm/pd-externals
(Above is the only entry coming from Preferences > Path.)
So one possible difference is that the "static path" includes my external location in Linux (that isn't speculation -- the stdout listing proves it), while it probably doesn't in Windows.
OK, then, let's grep staticpath... this leads to s_path.c, which says (in an ifdef for Linux):
sys_expandpath("~/pd-externals", pathbuf, MAXPDSTRING);
STUFF->st_staticpath = namelist_append(STUFF->st_staticpath, pathbuf, 0);
So user-home/pd-externals is a special, hardcoded location for Linux, which I happen to be using for my externals.
Looking a bit further down, hardcoded locations in Windows are AppData/Pd and something about common-program-files/Pd -- but the Pd GUI recommends Documents/Pd/externals as the installation directory. (And Mac will have a similar problem, because the hardcoded locations include ~/Library/Pd but again not Documents/Pd/externals.)
I'm satisfied that this explains the difference in behavior between the two environments. But it leaves a bit of an impression that this hasn't been completely thought through. If there are magic locations for help browser search, ideally this would be coordinated with recommended installation directories, but they aren't.
hjh
Is there a better way to get Benjolin to work on Pd Vanilla 0.50?
Howdy folks,
Looking to make some chaotic feedback sounds, I found this old post at macumbista.net ab0ut a PureData Benjolin port.
I followed the instructions there; the good news is, it's working for me in Pd Vanilla 0.50 on OS X, and I can resume making quietly bent noise. However: I had to do a bunch more than what's listed there to get it to work. So I'm posting here to explain (a) what I had to do, for the sake of the next poor bozo that tries; and, (b) to wonder aloud whether maybe I didn't do it the best way--I'm pretty sure I didn't; see below.
Without doing the following, I was getting a lot of "couldn't create" errors for the objects/modules in question.
(a) What I had to do:
- Add all the externals Derek Holzer mentions in the original post under my Pd externals dir;
- Plus a few more: flatgui, ggee, list-abs;
- I had to move matrixctrl and mmb inside my externals dir -- I couldn't figure out how to get searching relative to the patch to work;
- I had to add everything to the search path; and,
- I had to hand edit (yikes!) the matrixctrl.pd file to replace prefixed abstractions e.g.
zexy/drip
withdrip
,iemmatrix/mtx_transpose
withmtx_transpose
, etc.
(b) Surely there's a more elegant way?
I'm sure there's a way to get the relative path search to work (#3 above), and I am really not happy to be hand-hacking the .pd source for matrixctrl.
Can anyone advise?
Thanks much
DF
PS: I've read through the sources I can find about externals management in Vanilla, e.g.
- https://forum.pdpatchrepo.info/topic/6743/how-to-install-externals-libraries-gui-plug-ins-etc
- https://www.derekxkwan.com/code/pdext-to-pd.html
...plus various forum posts about extended->vanilla migration. Although I get that there should be a better way, this was what I had to do to "make" it work.
ofelia GLSL shader loader
I made a GLSL shader loader with ofelia. Most examples from http://glslsandbox.com work without modifications (like the examples that i included). While the examples from https://www.shadertoy.com do not work out of the box.
A lot of other shader examples do not work at all (perhaps because I did not modify them right?).
Or is it possibly because of the wrong GLSL version?
What I am searching for are mainly video effects, especially a video delay (something like that: ).
It would be great if there is already a shader like that which works with ofelia.
One question: Somehow Pure Data complains about a missing .vert file, but it is still working fine without. Can I make something like this:
void main()
{
gl_TexCoord[0] = gl_TextureMatrix[0]*gl_MultiTexCoord0;
gl_Position = gl_ModelViewProjectionMatrix*gl_Vertex;
}
as a .vert file dummy? At least it seems to work.
I set this GLSL variables in ofelia (because they fit to the sandbox examples):
uniform float time;
uniform vec2 mouse;
uniform vec2 resolution;
Getting chaos-0.2 to run in Purr Data
edit: solved
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