Hello everyone, I'm currently working on somekind of "fork" of a patch I found(it's a groovebox patch coded by Martin Birkmann). It consume quite a lot of CPU, on my current Laptop equiped with an Intel® Core™ i3-6006U CPU, it ran up 50% on the first core. Since i want to be able to run it on a Raspberry Pi 3, running the patch at about 1 ghz on a single core is just not possible. Then I looked up how I could optimizes the use of the cpu, I tried to use some puredata command flag, tried to simplify and hide most of the GUI and even tried to split up the patch with subprocesses with pd~.

First flags, changes of priority, realtime ect... doesn't do anything for the use of CPU. Secondly hiding some GUI maybe help to grab 1% or 2% of CPU. Finaly, I had great hope that pd~ would allow to spread the CPU all across the proccessor allowing me to run it on the RPI 3, but no it's strange the mother patch of the subprocesses is running at 18-20% of CPU use(about 60% on a single core) consuming more than the initial patch that runs at 10-12% of CPU use. And when I'm running the pd subprocesses they also grasp a load of cpu use, They consume about as much as the mother patch, which is quite the opposite of what I wanted...

So is it normal that the use of pd~ just increases the need of CPU time for pd ? Is there another way to split the audio processing in different pd instances s the calculation is shared by different cores ? Is there some things I could improve in the audio processing section that could help lowering the use of CPU ?

Then I have another problem whenever I wanted to activate the dsp when I was on my RPI pure data craches. Is there someone here that knows why ? What command should I use to use the dsp without crash on a rpi ?

If you don't see any solution to my problem then you maybe can help me in an another way? Since my problem is mainly optimisation, if you have some recommandation to gave about some pure data open source groovebox patch that run well on low spec system it would be great.

@liamorourke Yes, probably best to start simple.
Here is an example using "graph on parent"...... GOP.
cart.pd

The patch itself will only work in extended. Many objects will be missing.... but that is not important.
Right click the window with the controls and click open and you will see what is inside.
The window is actually a sub-patch called [pd guts]

Once it is open you can right click anywhere on its background and a properties window can be opened.
The properties control the GOP..... whether its name is shown........ whether the GOP is active...... the size and the position of the GOP window in the sub-patch (the red box).
The size is reflected in the mother patch [cart] but the position is the position of the window through which you are looking into [pd guts]
"size" is obvious. "margin" sets the position of the box relative to the top left of the window.
Nothing outside that window is shown through the GOP, and no connections are shown even within the window.
David.

@cfry It had worked in the past (32-bit extended +RPI2B + wiringPI) and can probably work now (vanilla + comport / python).
It is complicated by the variables introduced.
Bits.... 32/64
Pd versions and available externals.
RPI versions and OS choices.

For example wiringPI was broken for 64-bit RPI3 last year, but is maybe working again now?
I am controlling my gpio pins directly on RPI3 with direct messages now (not in Pd but it is probably possible)....... like.....
os.execute("gpio write 25 0");

where "os" is in the standard lua library.
I am still a Linux noob....!
I have a startup file that sets the pins as I want them.......

#! /bin/bash 
gpio mode 17 output
gpio mode 27 output
gpio mode 18 output
gpio mode 22 output
gpio write 22 1
gpio mode 23 output
gpio write 23 1
gpio mode 25 output
gpio write 25 1
gpio mode 24 output
gpio write 24 1
exit 0

And I understand that Pd can do this through [shell] but I don't know which library that is in......?
For reading the pins...... Adafruit retro games...... https://forum.pdpatchrepo.info/topic/11564/how-to-use-disis_gpio-for-rpi-button-input-alternatives/3
David.

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

@Jakki Hmm. It looks like there is just one object missing (well, not missing, but corrupt)....... whatever was top centre of the patch and in every copy of [pd MY_RSP_HID_PRECISER]

Other objects are missing for me on windows..... which is normal.
The worst problem is that all the connections in the patch are lost, but there is a remote chance they will come back when the problem is solved.

The patch is not going to recover the object I think. The object might still be working though.
Make a new patch and "put" that object onto a clean canvas. If it creates then it should be ok.
If not you will need to replace it, from wherever it came from.

I don't think you should edit the raw text contained in the patch in text mode. The chance of not making a mistake and destroying it is very high.

Make a backup of your patch from Pd.
I just deleted the "red-dotted" object above [hidio] and a couple of them in pd MY_RSP_HID_PRECISER ....... and saved the patch, and all the connections in the patch came back on reopening, which is good news.

If every copy of pd MY_RSP_HID_PRECISER was identical then I would.....
Make a new patch called MY_RSP_HID_PRECISER ........ so an abstraction, without the pd prefix.
Put the object inside.
Save it.
Then rename every copy of [pd MY_RSP_HID_PRECISER] in your patch to [MY_RSP_HID_PRECISER]

You can do that if they are all different, but you will need to use $ vatiables and arguments.

David.
PS....... I see there are a load more bad objects hidden away in the main window.
But they all look similar. Any idea what they were? Could you upload the object that was inside [pd MY_RSP_HID_PRECISER] (In a ZIP folder is easiest).

@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.

1. 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.
2. 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.

@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.

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.

closetest1.pd

close_patch5.pd

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

@Ale-H.H. Hello........ sorry, I was very tired and ill and panicked, being in too much of a rush...... and I forgot to include [part_timbre] and [part_voice] in the zip. Here it is again....... NEW3.zip

Yes the main patch is 1_vod_5.pd
[pd gubbins] is a "sub-patch". It is part of 1_vod_5 and saved as part of it. It is like a window onto another room within 1_vod_5 that can be closed (hiding the contents) giving you more space to use on the main page. You will see that it does not exist on it's own..... there is no "gubbins.pd" in the folder.
If your main patch window fills up with too much stuff you could make another sub-patch. Put an object [pd whatever] and you will see a new window pop up. Cut and paste some stuff from the main patch window that you rarely want to look at into the new window..... close it..... and save the main patch. The "stuff" is still there and will behave as before (it is in the same patch) but is "hidden" unless you choose to open the window.

[voice_gen1] and [voice_gen2] (( and [voice_gen3] etc. if you need more voices)) are abstractions BUT they have to be kept separate, by having different names, because of the graph data that they contain.
Yes..... if they had the same name they would be true abstractions. But if you saved one the others (copies) would change, and you would always have the same graphs in every copy.

[part_voice] and [part_timbre] are true abstractions. Every copy is identical in every way...... but.... when you give the copies different arguments they will receive from different places, set their frequencies and volumes in different ways, and send their output to different places....... all controlled by those arguments.... $1, $2 etc.
David.