@oid said:

@esaruoho If you are trying to save CPU than I would just separate UI and DSP, run the UI in its own instance of PD and DSP in another, communicate between them with [netsed]/[netreceive], there comes a time in PD when you just have to either separate UI and DSP or sacrifice. Beyond that it is difficult to say, I do not know what your needs are and what sacrifices are acceptable. What are your requirements? I can optimize these patches in a dozen different ways but I have no idea if any of them will meet your needs since I do not know what your needs are or even why you are trying to change things beyond a vague notion of there possibly being something better.

ok. i have heard about this UI DSP separation. so.. is it a case of every single slider for instance needs to do a [netsend] to some other abstraction that only does DSP? or have two separate patches altogether, one for UI and one for DSP? sorry, i'm really vague on this.

So, my main painpoints with the current channelstrip is that when I set up 16 "LFOs" to "breathe" up and down the volume slider (which also has slider-color-changing while it is moved from 0 to 1) - when i have more than 4 of these LFO counters cycling from 0...1 on the channelstrips, all sliders stop updating. it might be 4, 8 or 12, but by the time i try to get all 16 of the looper volumes to cycle from 0...1 (my "breather" has a setup of cycling from "min-max every 2 seconds" to "min-max every 60 seconds") -- and that to me makes me think that the UI is not as optimized as possible.

i keep hearing that ELSE library supposedly has some larger crossmatrix/channelstrip that i could use, but i have not looked at it.

so ideally i'd prefer to take the channelstrip even further, i.e. have all effect sends be modulatable (well, that word where the effects have LFO modulation) so i could have even larger more complex things going on where the channelstrips that receive audio from loopers, are sent to specific sends like reverbs, delays and so on. this kind of larger modulation on all parameters would be really useful.

the way the channelstrip is built is that the dwL and dwR go to a separate [diskwrite~] abstraction which i use to record audio. the "p" (and p1-p8) defines that any channelstrip that has p enabled, is sending to all the other loopers - so in that case, any audio that goes to a channelstrip, can be sampled into the 64kb loopers (16 of them).

also i have thechannelstrip labels (i.e. volume slider name) dynamically written to, so i can always have them easily understandable / informative.
here's the "init state". i use bunches and bunches of loadbang -> message -> senders to get them to a specific state. .

one thing i've been toying around as an idea is to incorporate highpass and lowpass filters to the channelstrips, and EQ. but i haven't figured out how to solve the EQ issue so that the single band peak EQ could be incorporated into such a small formfactor ( the width is only 38 and height is 189 so it's hard to conceive how an EQ could be usable there).

i also have for the 16 channelstrip looper instances, BCR2000 + BCF2000 volume slider control and so on. but i'm willing to take the whole setup "to the dock" and rewrite it, if i could be sure that it will be lighter on the cpu..

so yeah, i do only have a vague notion of "maybe it could be better, i'm not sure?".. but i've not yet seen much netsend + netreceive stuff so i'm not entirely familiar how it could be done and how much i need to rewrite (i.e. does everything need to be netsend+netreceived with a complete split of DSP and UI, to reap the benefits, or can i just try it with the 16 loopers and see what happens?

@romulovieira-me In your Pd/bin folder you will find an executable.... pdsend.exe for windows...... or pd.darwin or pd.linux (I think) for other os's.
You can tell Lua where to find it (maybe just copy it into a folder that Lua uses), and call it within your script.
In Pd you would then use [netreceive] to receive the message.
It will probably be a lot easier than creating a socket in Lua.
I don't know Lua.
You would use pdsend (in Python) and [netreceive] (in Pd) like this........ https://guitarextended.wordpress.com/2012/11/03/make-python-and-pure-data-communicate-on-the-raspberry-pi/
You will need to work out how to script the Python equivalent in Lua.
David.

@60hz You might be able to redirect a comport to your cheap usb device.
It is possible in windows using.......
NET USE COM1: //pc_name/printer_share_name /persistent:yes
The usb device has to be shared first......
https://superuser.com/questions/923426/how-to-map-a-virtual-com-port-to-a-physical-usb-port
The proviso about plain text would not bother you for a dmx dongle.

Further down the same thread you will see a link to https://ftdichip.com/drivers/vcp-drivers/
..... and on that page the virtual drivers for windows.
They mention "D2XX Direct drivers" are included...... and I have a very vague recollection that it is they that do the FUDI stuff.
They only mention windows....... and then further down the page are drivers signed by Apple, and quite a few others.

The virtual drivers should make the device appear as a comport.
You can see on Amazon that a few people needed these virtual drivers to make the device you have work with FreeStyler....... where they then select Enntec DmxPro as the output.

In Freestyler selecting the Enntec is essentially choosing to communicate through a comport rather than through a driver interface.
When you select the DMX Pro in Freestyler it asks which comport (years since I have used it... but pretty sure)
David.

P.S. I forgot to mention yesterday that you could send your data directly from the RPI using Python (maybe Python is already involved) and call pdsend....... probably pdsend.linux which is in the Pd folders somewhere.
That would send directly over Ethernet to a [netreceive] on your computer.
Approximate usage..... https://guitarextended.wordpress.com/2012/11/03/make-python-and-pure-data-communicate-on-the-raspberry-pi/
I assume (I do that a lot) that
pdsend (your computer IP address):(port) would send correctly...... something like pdsend 192.168.1.33:3000 would send to [netreceive 3000] on your computer.

You mentioned an Ethernet shield...... does your RPI not have an Ethernet port built in ?...... I thought they all have one.

@KMETE The rpi can also communicate with Pd using pdsend..... probably pdsend.linux in the Pd distribution. You could call pdsend in your Python code (probably copy it into a folder where python can find it).... and send a trigger message..... usb_connect 1 to a [netreceive] object in your patch.
When the message arrives in Pd use that to trigger the "open" connection of [comport].
Example code....

In the case of the above code you would use [netreceive 3000] in Pd.
David.

@timothyschoen Thanks for the great work! I tried it with Bitwig 3.2.8 on Windows 10, opened a patch and heard sound.

Some observations:

Selecting help from the right-click menu worked on some objects, but not others. For example, list and netreceive showed the help file, but metro and phasor~ gave message "Couldn't find help file."

Arrays were retained in my opened patch, but editing the values with the mouse was inconsistent, sometimes values would move to the cursor position and then jump back to their previous position. One array showed the dots for values and the other showed nothing but seemed to have correct values being played. Names of the arrays weren't shown, and I couldn't find a way to edit the array properties.

I probably shouldn't expect to receive OSC data from my Android phone, but I tried sending a "listen 8000" message to netreceive and got the error "netreceive: listen failed: The operation completed successfully."

I find this an exciting project and hope it continues to develop.

@ludnny You can send [send pd dsp 1(
and in the receiver.......
[netreceive]
|
[route pd]
|
[s pd]

As ";" is simply a local shortcut for [s] that allows a message to be sent to an address from within a message....... see my next post.

OR.....
Send the message [send addsemi, send add2 pd, send add2 dsp, send add2 1, send bang, send set(
and attach an empty message box to the outlet of [netreceive].
Of course you could use [list prepend send] to shorten that message (the list will still need to be comma separated for it to work...!).
Something has to be attached to [netreceive] for the message to take effect at the receiving end.
In the screenshot below I have turned DSP on in Pd Extended by sending that message from a Vanilla instance.
David.

@nicnut 2nd question first.
You need to know the ip address of the computer you will send to....... so really, if you want your patch to work next year it will need a static address.
However, I think you might be able to replace the ip address with the host name.
Anyway, there is an example here........... https://forum.pdpatchrepo.info/topic/10136/netsend-netreceive-os-x-pd-0-47-0/2 with [netsend] in udp mode.
But you can broadcast also with [netsend].... see below.

1st question.
[udpsend] is available for Pd but you need to install either the MrPeach library or the iemnet library or the net library.
It has multicast but for broadcast you can use the reserved broadcast address for your network.
And you can do the same with [netsend].......... https://forum.pdpatchrepo.info/topic/11062/cannot-connect-to-broadcast-ip-on-linux-via-netsend
David.

@FFW So finally i came up with something:

wait.zip

The bangs from the triggers have to run through without pause. Then the checkpoints will only fire when they receive a simulated signal from netreceive in the order they received the initial bangs.

So the actual process after the initial bang is completely detached and asynchronous. It does depend on receiving the simulated netreceive. This can be replaced by an actual [netreceive].

I am not sure if this is reliable or stable or anything, more like a prove of concept.

Just to mention: As far as i know there are no "states" in Pd, with which you could put parts of the code to sleep or wake them up. Pd is just running continuously, waiting for input, then calculating everything. The same with [netreceive]: It just puts something out, when it receives something, so generating a bang.

You could define a state "received" and check for that state with a metro in other parts of the code. But this is not only ineffincient, the state would still have to be changed by [netreceive], so this could just trigger the next part of the code.

@ingox The problem is in

[bang(
|
[t b b]
|       \
[code b] [code a]
|        |
[code c  ]

if it has a [netreceive] in [code a], [code c] is computed before [code a] returns a value.

And as [code b] doesn't need [code a] output I can't chain [code a] to [code b] without the mentioned "bang-when-done".

with the waitings for [netreceive] inbetween.

It's really what I'm looking to remove