@chvolow24 said:

What would prevent the responses from being received, output, or printed by netsend?

UDP is a dumb protocol: no handshaking, no confirmation of message receipt -- it's "I sent it out the port, then we just hope for the best."

Lack of handshaking means (AFAIK) UDP doesn't have a concept of sending back to the originating location. Because it's dumb, it's simpler: [netsend -u] only sends, [netreceive -u] only receives. The idea of passing a message into [netreceive] and it being sent somewhere doesn't make sense in UDP land.

In the helpfile, the "send back" functionality is demonstrated for TCP connections but not for UDP. I don't think this is a casual omission -- I think this actually reflects the functionality.

hjh

@ben.wes said:

actually, there has been quite some work on it in the recent months - including updates of the pd version (to 0.54 - so 0.55 is still due). the current builds on github are just 2 months old

Thanks, that's good to know. The other thread mentioned a much older source.

hjh

One thing I picked up from another thread here is that Purr Data is several Pd versions behind the main line (perhaps even a few years behind). If vstplugin~ depends on relatively recent functions, it might be incompatible with Pure Data. But I can't be more specific.

hjh

Which version / flavor of Pd? (Pure Data, or plugdata, or purr data... and version number.)

How did you install gem? (The answer to that question provides information about where gem is located in your filesystem, which is important for solving this problem.)

hjh

@raynovich No need, it was just a grumpy moment in the morning before coffee. Glad that I could point you in a good direction with the patch, no worries.

hjh

@raynovich said:

So part of my frustration as I read your initial help was that you did not include the '/' in you example:

I.e. not cd xxx/yyy/zzz && ls, but ls xxx/yyy/zzz. (See above)

I guess my thinking here was that xxx/yyy/zzz was meant to represent any path, including absolute paths -- the important thing about the example was the format of command, not the relative-ness of the path placeholder that I wrote.

I'll also say that I feel a bit like I'm getting criticized for omitting one character that would have been helpful. Which... nah. Sure, it was a mistake, but... I'll continue to post at times, and some of those posts will have errors.

So, I think my question about ofelia still "somewhat" pertains. Perhaps you know the answer?

Why does ofelia make unix commands include a backslash before the beginning of the path?

Whereas if ofelia was never opened it does not need the backslash?

I look at it this way. When you use relative paths, the behavior of your code depends on something outside of the control of your code: the current working directory. That's a risk factor: you might get away with it, or you might not. Whereas absolute paths are, well, absolute -- every absolute path leads to one and only one location -- so, no risk of cwd messing that up.

Clearly ofelia is changing the Pd process's working directory. That's a bit rude -- I'd assume that externals would try to minimize side effects outside of their own scope -- but if that's what it's doing, then you just have to avoid dependence on a specific cwd.

Or: "It works sometimes, so it should always work" is not always a realistic expectation. I think it's more realistic to think, "If it doesn't work sometimes, then it's not reliable, so find another way."

hjh

@raynovich said:

Thanks for the response. I still think cd is not working in shell or command. I am trying to do the same actions in terminal as shell and command.

My whole post was about why these objects are not the same as a terminal window.

You're programmatically generating the commands, so you can programmatically generate them with full paths, and not use cd.

Why "not use cd"? Because as you've already found, cd is unreliable with these objects. So you kinda have a couple of options here: 1/ complain, and not make progress; 2/ generate the commands in a way that avoids the failure point and is certain to work, and move forward today with your project.

E.g., to work just with the filename upstream, and concatenate the path only at the moment of building the command:

EDIT: Symbols needed to be tagged -- this patch works:

EDIT: Oops, the [t] object should be [t s b].

hjh

@raynovich said:

Does ofelia take over the "terminal" or some other function for Pure Data if created?

TL;DR Probably the best solution is for you to construct the commands with full paths, pointing exactly where you want, and do not rely on the current working directory.

I.e. not cd xxx/yyy/zzz && ls, but ls xxx/yyy/zzz.

Why?

"Shell" functions (as I understand it -- maybe it's different in some programming environments, but this is my observation) generally don't persist their state.

That is, if you open a terminal window, there is one shell, and every command operates on the same shell. cd changes the current working directory of the shell, and the next command remembers the new cwd.

An object like [shell] is like opening a new terminal window for every command. Every invocation starts from scratch. So you should not expect it to work if you ask shell to first cd, then ls. (You said this worked, but I was not able to get that behavior on my machine.)

SuperCollider has a couple of ways to do it that illustrate the issues involved.

"ls".unixCmd;  // user home

"cd tmp".unixCmd;  // no output, OK

"ls".unixCmd;  // still user home

The cd did not affect the second ls -- because it's like: terminal window 1, ls; terminal window 2, cd; terminal window 3, ls and why would you expect window 2 to affect the behavior of window 3?

Many shells, when parsing the typed input, can handle a series of commands separated by &&:

"cd tmp && ls".unixCmd;  // lists ~/tmp, OK!

But this is a parsing feature. If a backend issues the command in a different way -- as an array of strings, where the first string is the command and the other strings are arguments, one by one -- this bypasses the parser (because the arguments are already parsed into the array), and the && trick no longer works.

"cd tmp && ls".split($ ).postcs.unixCmd;
[ "cd", "tmp", "&&", "ls" ]
(and no `ls` listing)

[shell], as far as I can see, works in this second way. A message like ls tmp works only if it's a list of two symbols. If you try to make it a single command string -- ls\ tmp -- then it fails, because there is no system command named l-s-space-t-m-p. (In SC, "ls tmp".unixCmd runs the command through the shell's parser, which splits a string into command-and-argument. That usage isn't supported in [shell]. Maybe it's supported in [command] but I didn't take a look.)

hjh

@atux said:

is there any object that allows to do a melodic inversion?

For chromatic intervals, just use [-] -- like, if you want middle C to be the reflection point:

(your MIDI note)
|
[120 $1(
|
[-]

For diatonic intervals, you'd need to convert to a diatonic representation, then subtract, and convert back.

hjh

@lacuna said:

I am highly interested in how to sync or interface Reaper or other DAW with PD control rate sample-accurately intra-blocks.

The second part of this video is about my approach to that.

hjh

@ddw_music said:

FWIW I'm planning to upgrade Ubuntu Studio over the weekend, after which I would be fully on Pipewire. I will try Bluetooth with that. I don't have high expectations, but let's see.

Finally did that upgrade (Ubuntu Studio 24.04): Pipewire could automatically switch between built-in audio, USB soundcard, and Bluetooth earpieces, and SC server (JACK app) could route audio to the Bluetooth earpieces without an apparent glitch (though I didn't try to push the CPU, so I don't know where the limit is).

So I'd say, if @bobfred needs JACK-ish behavior with a BT headset, Pipewire is very likely to be a good way to go.

hjh

@oid said:

@ddw_music I'm guessing this had SuperCollider in the mix so you had to use jack?

Yes.

With pd you could do it all with alsa...

Sure. The question was, how to get the Bluetooth headphones to show up in JACK, and the answer was about why that isn't a good idea.

FWIW I'm planning to upgrade Ubuntu Studio over the weekend, after which I would be fully on Pipewire. I will try Bluetooth with that. I don't have high expectations, but let's see.

hjh

@bobfred said:

How can I view a bluetooth output in jack so I can send these outputs independently to seperate devices?

JACK cannot do this. Period. JACK's timing requirements are far too strict for BT. Period.

(For sake of completeness: Some years ago, I tried to hack it using bluez-alsa and I did actually get JACK piping into Bluetooth earpieces for a short time, with a ridiculous buffer size of 8192 samples x 2 periods, like a quarter-second latency But then JACK would always hang within 15 minutes, and it was impossible to restart the JACK server without rebooting the whole system. So I found that this was not an especially joyful way to work and I gave it up.)

Pipewire might be able to do this.

hjh

@blindingSlow said:

• What I'm curious about is if there's any other Pd flavour (or plugin) that will offer the same as Plugdata

To my knowledge, the tcl/tk "standard" pd interface doesn't and probably will never do that. Pdnext is an offshoot of the tcl/tk interface and only adds bezier-curved cables but not the ability to segment them.

Purr Data might have this, but I don't know.

I'm not aware of any pd front-end interfaces other than the tcl/tk one, Purr Data and PlugData.

hjh

@SCFan32 said:

is there some ressource to search for specific functions like in the help browser of SuperCollider?

Also consider plugdata. The GUI is more modern (Max-inspired). Object boxes perform an autocompletion search while you're typing. In your case, you'd have typed "osc" and oscformat would have been in the list.

At one point, I tried an autocomplete tcl plugin for pd, but it didn't work for me.

hjh

@seb-harmonik.ar said:

@ddw_music I'm pretty sure there's an option to display all of the searched paths that get failed trying to load a certain class, if you run pd at higher verbosity. It will be like "tried xxx and failed" or something.

I tried log level 4 (maximum) and I don't see any such messages.

hjh

@oid said:

Might want to check the pd github, there is at least one pd killing bug when using Pipewire's Jack, saw it yesterday but did not look into it since I have also let updating my system slide and don't feel like updating quite yet.

The only bug report I see is that it fails when you toggle "use callbacks" -- so it looks like the old joke, "'Doc, it hurts when I move my arm like that!' -- so don't move your arm like that."

Btw I use both Pd-next and plugdata -- I'm not at all a fan of the Tcl/Tk interface, though, so I tend to reach for plugdata first. But if I'm making an abstraction that I know people will use in vanilla, then it makes more sense to build it in vanilla so that it looks nicer in that environment.

hjh

@whale-av said:

@ddw_music A lot of complaints of the same with externals lately.... always on a recent Mac.
What is this students machine /OS?

It is mac, not sure the version.

You could try putting one of the abstractions in the Pd/bin folder. If it is then not found it must be an os security problem?

I guess I'd have assumed that macOS would treat a text file (.pd) as "just data" and not as an executable that could be quarantined. Also, I tested with a cyclone binary external (play~) and no problem, but the pure-vanilla abstraction failed.

Are there any additional log messages about objects that couldn't be created? "... couldn't create" isn't enough information to troubleshoot this problem. Is it because the file wasn't found? Or was there something wrong in the file? Or permissions...? I can only guess.

hjh

Copied hjh-abs/ into a student's Documents/pd/Externals folder.

Added Documents/pd/Externals/hjh-abs to the paths.

None of the abstractions in that folder are available ("couldn't create").

cyclone is also installed and in the path -- and there's no problem.

So how should we fix this? I never had this problem with my abstraction folder before.

hjh

@rph-r said:

but anyway I'll figure out how I could use [sf-varispeed2~] since I need to fine tune and resync. I have to guarantee the installation for 5 years (!!).

BUT... the bad news... I just noticed that you said the files are 10 minutes. sf-varispeed(2)~ depends on loading the file into an array, where the Pd-canonical way to stream it out is by feeding sample indices to tabread4~. (This is under the hood of sf-varispeed~.)

32-bit floats are precise up to about six minutes or so. There's nothing Pd can do about that (except if you build a 64-bit version -- not sure how that would run on a Bela). This isn't Pd's fault btw -- SuperCollider's BufRd has the same limitation.

So I guess your choices are:

• [sf-varispeed2~] and split the files across multiple buffers, trying somehow to hide the seams. (Or, split the files and work out your own play mechanism that crossfades over the seams.)
• OR: Sample-rate-convert the files. You could have, on your dev computer, a "myfile-0-44100.wav" and a "myfile-0-48000.wav" (and myfile-1, myfile-2 etc.) and then select the file by a numeric index and sample rate:

Then when you move the patch over to the Bela, just copy the -44100 file and the patch will still find it according to the sample rate.

@oid

Edit: I suppose it could also be the case that your soundcard is 48k only?

That could be -- it's the case on my current laptop. If I request qjackctl* to start at 44.1 kHz, it will not do that for the built-in sound card -- 48 kHz only.

• I know, I know... planning to upgrade to Ubuntu Studio 24.04 over the winter holiday... then hello pipewire.

hjh