@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