Hey all,

I am integrating a Pd patch with an existing sequencer/looper (Seq192) with an OSC interface, where my patch should convert my MIDI controller's button presses to OSC commands and send back MIDI signal out to lighten the controller's LEDs.
I can retrieve periodically the status and details of all clips/sequences and aggregate it into a list of parameters for each sequence. The LED colors and the actions that the next button press will trigger depend on these parameters, so I need to store them for reuse, which I like doing with [text] objects. I am then handling buttons' light status in a [clone 90] (where each instance of the clone handles one button).

This should be running on a fairly low-end laptop, so I'm wondering which of these approaches is the most CPU-efficient - if there is any significant difference at all - and I couldn't come up with a way to properly measure the performance difference:

1. one [text define $1-seq-status] object in each clone, with one single line in each. I compare the new sequence status input with [text get $1-seq-status 0] so that I update only line 0 with [text set $1-seq-status] when I know that the content has changed.
2. one single [text define all-seq-status] object with 91 lines. I compare the new sequence status with

[ <button number> (
|
[text search all-seq-status 0]
|
[sel -1]
       |
       [text get all-seq-status]

and if it has changed, I update a button's line with

[ <new status content> (
|
|      [ <line number> (
|      |
[text set all-seq-status]

The order in which buttons/sequence statuses are listed in the file might change, so I can't really avoid searching at least once per button to update.

3. Should I instead uses simple lists in each clone instance? As far as I could test, getting a value from a list was a bit slower than getting a value from a text, but searching in a text was much slower than both. But I don't know the impact of processing 91 lists or text at the same time...

TL;DR: Is it more efficient to [text search], [text get] and [text set] 91 times in one [text] object, or to [text get] and [text set] 1 time in each of 91 [text] objects? or in 91 [list] objects?

Since you've gone through this long post and I gave a lot of context, I am of course very open to suggestions to do this in a completely different way :D
Thanks!

@whale-av said:

I am almost certain that Gui objects in TouchOSC can talk midi and OSC at the same time.
But I doubt that it will communicate over wireless (required for OSC messages) and USB at the same time.

GUI objects in TouchOSC can send Midi and OSC at the same time, and wired USB connection does work for both, no issues. no need for having the iPad on Wi-Fi. just takes a while for TouchOSC on the iPad to realize what the IP address of the laptop is.

The communications between Pd and touchOSC are set in the abstraction [osc-s-r] within the [globpitcharray1] patch in the zip I posted.
There is a TouchOSC layout plom.touchosc in the zip that should be used with this patch (for a test demo).

thanks for breaking this down for me!

You would need to fix the IP address of the Ipad (static address) and use that address for [netsend] and [netreceive] in [osc-s-r] ....... if you ever get over your fear of using Wi-Fi for this.... or just feel like trying it to see what it will do.......

yes, [osc-s-r] is definitely where it's at. thanks for spelling out the [netsend] and [netreceive] to me, cos looking at the screenshot i had, i can now realize where to input 11000 and 11001 for send + receive. the connect portion of the script was throwing me.

i hope i have it right now,

@esaruoho said:

I could try again, but it looked like UDP required me to know the IP address of both the laptop and the iPad, and that really threw me (i don't know how to figure out what the IP address of the iPad is, or how to make sure it's always the same, same for macOS).

Ah right, for bidirectional communication.

Actually in the netreceive help file, there is a flag for this: "optional -f flag for from address & port outlet (0.51+)".

Help file example prints from: list ::ffff:127.0.0.1 57120 where ::ffff:127.0.0.1 is an IPv6 address.

So...

... should configure the [netsend] to send to the first address from which messages were received (and I did a quick test, which worked). If you enable "Ping" in TouchOSC, then it will automatically send a message to the computer, which will trigger the "connect" logic right away.

Incidentally, I didn't know about this feature (never used the "from" address in Pd). My thought process was, "Well... this is a very common requirement, so let me have a look at the [netreceive] help patch and see if there's anything about 'from'" -- and toward the lower right, there's a [print from] box. Hm. Then, what's different about the [netreceive] feeding it is that it isn't only "-u -b xxxx" but rather "-u -b -f xxxx"... what's that "-f"? Then, looking up from there a little bit, there's a list of object creation flags, where "-f" is explained.

So the solution exists, and documentation for that solution is actually reasonably clear.

i have maybe an hour every 2-3 days to try and get something going, and also feel a bit like there's no "TouchOSC with PureData for idiots" blog-post for iPad / macOS going on, or at least i haven't been able to find it.

This I fully understand.

Pd OSC sending, like this. It won't send anything until after you push a connect ip.ad.dr.ess port message into the netsend inlet -- as noted above, you can get the parameters for the connect message from [netreceive].

... producing messages like /1/toggle1 1.0 or /1/toggle2 0.0. This type of message format is what you need to change a control's value on the tablet.

It's also possible to "set" the OSC command path before providing the arguments -- but try the simple way first.

hjh

@esaruoho This being a new thread I had forgotten that you were using a wired USB connection.
Yes, that means that you are limited to midi only.
It will be possible to talk both ways but you will be limited to 127 steps for your controls.. so much lower resolution than OSC...... unless you use the pitchbend in TouchOSC and the [bendin] and [bendout] objects in Pd..... see below.
Also I am not sure that you can change data and colour for the same GUI through midi, but you could use 2 GUI's.... a fader and a "push" button or text label above or on top of the fader for the colour.

The 127 step resolution can be improved using pitchbend to get 14-bit resolution...... https://vi-control.net/community/threads/touchosc-has-been-updated.110551/page-3

I am almost certain that Gui objects in TouchOSC can talk midi and OSC at the same time.
But I doubt that it will communicate over wireless (required for OSC messages) and USB at the same time.

So the patch I posted was for OSC wireless....... sorry.
The communications between Pd and touchOSC are set in the abstraction [osc-s-r] within the [globpitcharray1] patch in the zip I posted.
There is a TouchOSC layout plom.touchosc in the zip that should be used with this patch (for a test demo).
You would need to fix the IP address of the Ipad (static address) and use that address for [netsend] and [netreceive] in [osc-s-r] ....... if you ever get over your fear of using Wi-Fi for this.... or just feel like trying it to see what it will do.......
David.

Hi, I'm looking for someone with a deeper understanding of PD and audio synthesis to help me understand why my patch sounds the way it sounds. I don't know why the audio is generated this way. I don't know if it is because of some expected behavior of square waves and the math behind it, or if it is because of some quirk of PD and the way I'm generating the square wave. If you think you can help, please stay with me, I don't know who to go to or what to study to help me understand this.

I was attempting to make a square wave from scratch, I saw some tutorials and I know there are more "proper" ways of doing this, but the simplest I could think of was -1 and 1 alternating. The osc I built is a metronome with a route alternating between -1 and 1 at a given hertz. But the result doesn't sound like a single square wave, there are some harmonics, almost like having senoidal waves mixed with the square wave.

Experimenting, I noticed a cycle of the resonances going from 1hz to 1378.125hz where it completely stops, like zero hz, or one tick in several, several minutes. Other cycles multiples of this frequency exist, like this:

n=1378.125hz
Cycle0 = 1 to n* 2^0
Cycle1 = n*(2^0) to n*(2^1)
Cycle2 = n*(2^1) to n*(2^2)
Cycle3 = n*(2^2) to n*(2^2)
? Cyclen= n2^(n-1) to n(2^n) ?

C0 and C1 are very similar, with subtle differences, but inside of C2 it seems like 2 times C0 or C1 (I didn't check it, but it sounds like this). Inside C3 there are 3 times, and next, C4, 4 times, and so on, the same cycle but more times and faster in each power of two.

I have made a patch that makes it easy to clone the osc to generate each Cycle. For example, clone 10 times to get audio files from C0 through C9.

Where do the resonances come from? Why these cycles exist? Are they some kind of harmonic series? Why 1378.125hz? Is this expected from the math, or is it a quirk result of some PD object (like inputing very low numbers to the metronome)? Does someone understand why this is happening?

main_oscs_cycles.pd
square-from-scratch-osc.pd used in main
square-from-scratch-osc-lineramp.pd used in main

@cfry I used the Arduino library "OSC" by Adrian Freed and in it there are lots of Arduino examples and a few Pd examples using the mrpeach library (which I don't use anymore since vanilla started talking OSC natively). If you can give me a better sense of what you are having trouble with I can make a more helpful example, e.g. do you need bidirectional messaging? What data are you passing (if any)? What Arduino library would you prefer to use (I see there are more now than when I started)? is it over WiFi or ethernet or something else?

But maybe this example from the OSC lib is all you need: UDPSendMessage.ino

Edit: I found my knockoff ethernet shield and wrote this Arduino sender and Pd receiver,. It includes an example of how to route numbers in the OSC path. Hope this helps.
testOSCSend.ino
osc rcv dump.pd

@Harlekin If you want TouchOSC to control OBS you don't need Pd....... just connect TouchOSC directly to the ports of osc4obs and make your remote.touchosc layout file.

If you want to do some other processing in Pd then connect TouchOSC to Pd directly (in and out)...... and then connect your processed control from PD to osc4obs directly (in and out).
osc4obs facilitates that by creating separate OSC in and out ports.
You will have to do that also if you want to use TouchOSC and Pd in an either/or situation as osc4obs only has one set of osc ports and is making a tcp connection with OBS.

OBS websocket is a tcp connection and so it is possible that osc4obs is requiring tcp for the OSC connections...... in which case remove the -u flag from [netsend] and [netreceive] in my examples below.
It could also be expecting ascii instead of binary in which case remove the -b flag (but I doubt that)....

Externals for Pd are written in C so if you are adept there is some help in Pd/doc/6.externs .....
Basically you need to make a websocket client that replicates osc4obs with outlets and inlets instead of the osc ports.

BUT... you could try the iemnet [tcpclient] first (NOT the [udpclient]...!).... and that should work.
Just replace both [netsend] and [netreceive] with the one [tcpclient]...... connect it to OBS and look at the output using a [print] object.
If OBS is on the same computer the connect message will be [connect 127.0.0.1 4444(
Remove the password from the OBS websocket unless you find that a password can be added to the [connect( message for [tcpclient]...... before or after the port number? preceded by "password" or "passwd"?...... guesswork...... and [tcpclient] might well not accept a password as it is not mentioned in the help file.
Once you are looking at a print of the received messages the problem will be to decode the proprietary message format (it will not be OSC)....... it might be easy.... or not.
If lucky there will probably be the ascii strings you are looking for or a decimal representation of them somewhere in the message.

If you go the osc4obs route then it is quite easy to use [oscformat] and [oscparse] in vanilla instead of creating an external.......
...... vanilla osc.zip

P.S. try to avoid integers within the OSC address (header) as they arrive in Pd as symbols at the output of [oscparse] ....... and are then difficult to route. So what/ever/6 data is best avoided if possible and what/ever/six data is easier to deal with in Pd...... but I have included a solution in the zip file above.

Be careful in TouchOSC to avoid message feedback (much like midi feedback)......... and the same applies in Pd. In Pd you can include "set" at the start of a message (without the quote marks)...... which will set a message in the next object or message box but not send it onward until that object or message is banged.
David.

@beem Yes, you cannot rename main.pd........ it's the folder that can be renamed.
@JackOats No. In edit mode drag across the [declare -path patch_editor_abs] with the mouse to select it and then copy it and paste it within the main.pd window before editing it.

If @beem has not solved the problem for you then.........

Let's try something else. Trying to find what is going on.
On your screenshot were a lot of the modules named in red and marked couldn't create.
Choose one, say basic-osc.
In main.pd click on the file menu and then "Put" "Object" and then type basic-osc into the object.
Does it create?....... pop up as a bigger window with the oscillator in it?
No?
Go into the patch_editor_abs folder and copy basic-osc.pd and paste it into the Pd/bin folder, or into the "extra" folder if there is one (the one that contains the ggee folder).
Back to main.pd and try putting the object basic-osc again.
No?
Yes?
If it does then try the module button for basic-osc.
Does it now work?
No?
Copy main.pd into the patch_editor_abs folder..... open it..... and try the first step again (put, object, basic-osc).
If none of that works then I think it must be a security permissions problem.
David.

mtrxsequencerbeta1.pd
Hi ! This is pretty beta for know but is working. There are some mistakes like use of subpatches when abstractions would have been better. I’ve been building this kind of matrix sequencer for Akai’s APCmini and Midimix. This requires no externals.

There are two sequences, a green one which goes up to down, from left column to right column
and the red one which goes left to right, from upper line to down line.

The outputs are for each note : the value of the corresponding faders (vertical and horizontal) of each grid’s button.

You can select the 64 buttons of the apc grid, which will output a value only if they’re selected (coloured in yellow), like a trigger. However there is also a trigger unsensitive output.

The midimix 8 first faders are for (from left to right) upper to down lines
the apc 8 first faders are for left to right columns

the 9th fader of midimix is for the lenght of the green sequence, the 9th fader of apcmini is for the length of the red sequence

there are also on the APC 8 buttons for each column and 8 buttons for each lines, there’s a little bug to fix there, as you have to tickle them a bit at the beginning to make them work properly (just press some of the buttons until they light on correctly)

the two sequences are a modulo of the sum of bangs received by the main metro. Modulo of the lenght of each sequence. This sum is multiplied by 1 to 8 thanks to the buttons. And divised by 1 to 8 thanks to these buttons when you also press the last square button which is between those round buttons. So if you multiply by one and divise by two, the sequence will be twice slower. If you multiply by two and divise by one, the sequence will be as fast buy will go from step n to step n+2, n+4 …
The interest here is to create polyrythmical sequences. I,e : red sequence * 5, green sequence *6, both sequences lenght = 60. and things like that. And it’s pretty graphic

okay.
Really sorry for my bad english. Hope this could help/inspire someone. And i would really like returns, as I’m a bit beginning in pd.
I will soon share a new version with abstractions in place of subpatches, in order not to modifiy each subpatches if you want to modifiy something (some places of the patch are 64 repetitions of the same thing, which could be a bit boring to do). mtrxsequencerbeta1.pd

@ddw_music

I'm afraid I'm not quite following you.

Let me try again.

Imagine you've got a single sequencer in the top level of a patch.

Feeding into its input, you have a global receiver [receive in]. (For the purposes of this example it's global. This is just didactic, and we could fix that later if we wanted.)

At the bottom of your single sequencer, you are connected to a [send] object with no argument.

Now, you are also going to build an abstraction which you can use with that same patch. It is not part of the sequencer, it's something different. Inside this abstraction you have something like this:

[inlet]
|
[list prepend $0]
|
[send in]

[receive $0-my-output]
|
[outlet]

Finally, you just have your sequencer slice off the head of the incoming message to [receive in], prepend it to the string "-my-output", and send it to the right inlet of the [send] with no arguments. Finally, you trim the list selector off the rest of the message and have your sequencer handle that message as it normally would.

This will result in the sequencer sending a message only a single abstraction instance.

Thus, you have a single state machine accessible by an arbitrary number of abstractions which can advance the state by sending and receiving their own arbitrary messages to and from that single sequencer.

but it also means there's no harm in extending the system's reach.

There is harm in extending it the wrong way. For example, the "init" message of the iemguis is often a harmful feature. Imagine tracking down an insidious bug in a program like this:

|
[float]
|
[tgl]
|
[== 0]
|

vs. this:

|
[float]    [preset_node]
|         /
|        /
|       /
|      /
|     /
|    /
[tgl]
|
[== 0]
|

If you get unexpected behavior from the first example and forget (or never knew) that there's an "init" checkbox for that [tgl], you have to do creative debugging in order to find it:

1. Right-click and open the dialog to check init state, probably because you hit such an insidious bug before.
2. Close Pd, run with the "-noloadbang" flag because you've learned that if that fixes the bug there is almost certainly an iemgui init or a [loadbang] deep in a subpatch somewhere.

But the one thing you can't do is simply read the patch! Not only can you simply read the 2nd example, the secondary loadtime data flow is immediately obvious.

I understand the desire to just say, "forward data to this object and return me the results." But depending on how it's implemented it could be a boon or a footgun. The obvious direction of pointing to "this" object using a gpointer don't work very well in a diagram-based language.