@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

@whale-av said:

I remember that [sf-play2~] can autocorrect, if it is available for your system.......

[sf-play2~] is an abstraction based on cyclone/play -- which probably rules it out for Bela.

In the same pack, however, there's [sf-varispeed2~] which is (I think) pure vanilla.

https://github.com/jamshark70/hjh-abs

@rph-r

I don't really understand why a simple and so common object doesn't work...

FWIW in SuperCollider you'd run into the same issue. The difference is that SC makes it easier by providing a unit generator, BufRateScale, that you can just plug into a Phasor or PlayBuf and get the right speed.

In Pd vanilla, you have to get the file sample rate from [soundfiler] and the system sample rate from [samplerate~] (and there's an interesting caveat about that, noted in the help file), and divide them on your own: playspeed = file_sr / system_sr.

I made [sf-play2~] and [sf-varispeed2~] and their supporting abstractions because I agree -- generally users shouldn't have to think about this. The abstractions do exactly what I just described, only behind the scenes.

hjh

WRT real-time audio, the most important performance factor is: will the next hardware buffer's worth of audio be ready on time?

If we assume a 512 sample hardware buffer and a 48 kHz sample rate, then each hardware buffer takes 10.6666667 ms.

If the audio calculations finish in 1 ms, that's roughly 10% of the available time. If they finish in 5 ms, that's 50%.

RT audio calculations tend to happen in bursts. IIUC (I could be wrong) system CPU monitors are looking for sustained CPU activity, which does not characterize RT audio. So the system monitor might tell you that the system isn't very busy, but the DSP thread might actually be stressed.

For instance, I just ran a bunch of DSP in SuperCollider and it reported about 38% CPU use, but the system task monitor reported 4%. (But htop showed one CPU core with high activity, and the rest mostly idle... so a single CPU usage number that aggregates all the CPU cores can also under-report.)

I think I remember reading here that Pd does its audio calculations outside of the audio driver's callback, and uses the callback only to copy data, meaning that audio subsystems like JACK in Linux might significantly underreport CPU usage. So the whole thing is a bit of a tricky question. I don't know how Purr Data is measuring CPU use.

hjh

Oh... if you want to load 13 images, you have to specify 12 in the "open" message.

No error message, no hints, silent failure cheers, then.

hjh

I have used pix_multiimage successfully in the past. But in this patch, I'm getting a fat load of nothing.

There is a folder adjacent to this file called "pix" -- in it, there are 13 files, pic0.jpg, pic1.jpg ... pic12.jpg.

Selecting any image 0-12 in the right inlet produces:

[pix_multiimage]: selection number too high: 1 (max num is 0)

I'm definitely clicking the "open" message, and no error is reported... but nothing is loading.

I dunno here, AFAICS I'm following the helpfile to the letter and doing stuff I've done before. So my guess is that the object is broken...? Can someone confirm?

hjh