I was starting on an abstraction to manage sound file sample rates and frame counts.

I had thought to store these data in a [text] where the first item in each line would be the array name.

The amusing thing is that a [soundfiler] "read" message may take one or more array names at the end (and, this is the only way to access more than one channel from the sound file).

So I would need to parse the "read" message and determine which of the elements at the end are array names.

A test using, say, [array size] prints an error message in the console upon failure -- but this isn't a normal situation where the user has made a mistake. "Failure" is a legitimate result (Boolean false). (That is, the assumption is that the user should know which arrays she has created -- but this assumption does not hold if you're creating an abstraction to publish. Therefore you need a way to ask the system without triggering an error.)

Alternately, I suppose I could modify the message format and tweak the list before passing it to [soundfiler], e.g. "read -resize path.wav - tableA tableB" -- the following does correctly isolate the items following "-". (I can't help thinking, though: If there is [text search], could there not be [list search]? This was maybe 30 minutes, vs SuperCollider's list.detectIndex { |item| item == "-" }).

The risk here is that users are not in the habit of separating the array names by "-" and the abstraction would fail if they forget.

So it would be ideal to stick to the standard syntax.

Is there some undocumented bit of magic to query silently for names?

hjh

@ddw_music If all the info is in your text file you could dynamically create the arrays first (in a clearable sub-patch) and then the read message....... from the text file...... name (1st list item)..... channel count (2nd list item?) so that they always exist.

If you dynamically create the whole file player then you could also play files with different sample rates at the same time
David.

@whale-av

Aha... That's a bit more than I can handle at the moment. I had looked a little bit into dynamic object creation, but it seems rather tricky to identify a particular canvas.

I think I'll just go with the "-" solution for now.

hjh

If you dynamically create the whole file player then you could also play files with different sample rates at the same time.

I sort of see what you mean... but, I don't want to impose a playback structure on the user.

In fact, supporting arrays with different sample rates is part of the point of this abstraction. You should be able to load any sound files, and it should know what is the sample rate.

The catch is... I found myself right back up against that function call/return problem. The instance of the abstraction is a single object that may need to accept queries from, and return results to, multiple locations -- particularly if the player of a single sound file is in a [clone].

What I came up with today was to query the table as part of the process of preparing the message sent to [clone]. Then there is a single point of access. That's fine, as far as it goes, but it doesn't feel quite elegant yet.

While I understand the "minimal core" philosophy, it would be a hell of a lot more usable if there were a subclass of array, say, "buffer" or "audiobuf," with a sample-rate property. Then it's trivial to do e.g. PlayBuf.ar(1, bufnum, BufRateScale.kr(bufnum), ...). I would love to get it to be this transparent in Pd. Playing a soundfile at its native speed should not be a hard thing.

hjh

@ddw_music Here you go......... simple.zip
The arrays are easy, the message less so...... but this will do it up to 4 tracks per wav........ and more can be added.
P.S....... you are still complaining...... https://forum.pdpatchrepo.info/topic/13134/things-i-wish-i-had-known-when-i-started-pd/26
David.

@ddw_music You can construct the [read( message by using the message change messages you can find on the bottom of the help file of messages in [pd changing-messages]:

@ingox ..... yes, a better solution..... I am getting old.

@ddw_music scalable version of dynamic arrays with auto read message setting for [soundfiler].........
simple.zip
Any track count.
David.

P.S. You could use [soundfiler] before this patch as well (needs recent vanilla)...... to get the channel count and samplerate..... and then feed that info into this patch and your player.
Done. (late vanilla).... simple2.zip
..........
But then you wouldn't need your [text] database........
But it would work with other files chosen at random

It's about the right time for you to get into dynamic patching....... or you will always be complainig..

Will look these over tomorrow, thanks. Dynamic patching has been inscrutable so far; perhaps a concrete example will help.

I had another thought after a walk. If the data are keyed by table names, then the keys are inherently global -- so the storage may also be global. So I could have a "read" abstraction and a "get stats" abstraction, both hitting the same [text] repository. That would also resolve the "function call" problem, because there wouldn't be a single stateful abstraction, but rather multiple abstractions accessing shared data.

As for complaining: Well, yeah. I didn't expect this would be quite so difficult. A month ago, I would have complained about the looping structures and list iteration as well, but I've got my head around those.

hjh

@ddw_music Maybe you can just lay out what you are trying to achieve in a broader context, so we can offer some solutions?

@ddw_music Dynamic patching...... a good place to start (removed from vanilla help..... -86 Million points).
0.all_msg.pd
For all possible messages that can be sent to a patch window to place objects and connect them together........ https://puredata.info/docs/developer/PdFileFormat
David.

To play a sound file with [tabread4~], you need to know the frame count (line end point) and duration in ms (line time). (Or, if you use an accumulator, you need to know the rate at which to increment the phase index.) This is trivial if the sound file's sample rate matches the Pd environment.

If I am giving demo patches to students, I have control over the sample rate of audio sources, but I don't necessarily have control over whether they are running at 44.1 or 48 kHz. So the patch must adapt to the environment's sample rate.

Also, when students do their own patches, it would be nice if the patch could adapt to any sound file sample rate transparently -- so, instead of giving start and endpoints in samples, give them in ms and let the software do the conversion.

Unfortunately Pd arrays know only their size in frames. There would be a good rationale to have a subclass of array, say, [audiobuf] with a sample rate property. Then it could implement methods such as duration, mstoframes, msscale etc. (or [audiobuf duration a1] etc.).

I could create an abstraction containing the array and the stats, but you're very likely to need to pass the stats out to different parts of the patch at different times = function call/return problem.

I've gotten this far. It's not 100% transparent in that the user needs to define the text (within the abstractions, it's "multiply defined").

sf-try2.zip

Inspiration here is from (of course) SuperCollider, where it's:

b = Buffer.read(s, "path/to/96kHz.wav");
b.sampleRate;  // 96000
b.duration;  // sensible

a = {
    // also here you have BufFrames and BufDur
    PlayBuf.ar(1, b, rate: BufRateScale.ir(b), ...)
}.play;

So it's really really easy. The buffer knows all of its properties and any part of the code can query at any time (and the result goes back to the part of the code that asked, transparently, no fuss).

I know, "you can get the numbers from [soundfiler] and save them where you need them" -- but why is it good to have to rebuild this design every time?

Huh... or maybe a better way is to have an abstraction that sets a number of [value] objects ([value a1ms], [value a1ratescale]...) and then the containing patch just uses the [value]s. (That sounds like normal software development... need to go through a few iterations before finding the right thing.)

hjh

OK, third approach, this might be about right. There's probably a better way to lay out the abstraction, but eh, I'm out of time.

After reading this on file, then you get a list:

• frames = [value xxxframes]
• duration (ms) = [value xxxdur]
• file sample rate = [value xxxsr]
• file sample rate / 1000 = [value xxxsr001]
• file sample rate / audio sample rate = [value xxxscale]

[value]s can be used freely, and I also threw in an abstraction to take a time point in milliseconds and scale it according to sample rate.

I can see one mistake still in there (either the endpoint should be start + time, or the time should be endpoint - start), but for a demo POC, close enough.

hjh

This is one of the reasons I ported a slightly tweaked version of matjus' [unpost] object from desiredata to Purr Data.

The object will re-route console messages (or just errors) to an outlet for a given stack. Essentially, like try/catch in other languages.

Such an escape hatch makes it possible to simply wrap something like [unpost] and [tabread] inside an abstraction to create your missing array namecheck functionality.

@ddw_music Yes, i see now what you mean with "function call/return problem". If you put an array or text inside an abstraction, you will get the "multiply defined" message and cannot easily use the same data from different places.

But the text and array functions do provide something like a function call/return structure, where you can have a central storage and access the data from various places, as you mentioned above.

Now that you cannot easily put the text/array inside the abstraction, you still can write abstractions that access the text/array within the main patch by using creation arguments.

Have the array in the main patch, create a general purpose abstraction to access the array data, give the array name as creation argument into the abstraction like [abstr array1] and access the array within the abstraction like [array size $1].

--

There are also ways to put the arrays inside abstractions and avoid "multiply defined", but they are not so obvious. I can expand on this if you like.

@jancsika This is great. Try/catch is a missing structure in Pd.

@ddw_music By looking closer to your patches i think you solved everything nicely.

@ingox said:

By looking closer to your patches i think you solved everything nicely.

Yeah, I'm kinda happy with this. Now they're up on github: https://github.com/jamshark70/hjh-abs

Now that you cannot easily put the text/array inside the abstraction, you still can write abstractions that access the text/array within the main patch by using creation arguments.

Sure, I'm familiar with that.

There are also ways to put the arrays inside abstractions and avoid "multiply defined", but they are not so obvious. I can expand on this if you like.

If you wouldn't mind... I'm curious about that.

I think I'm at the stage where I'm fairly comfortable with the basic cases, and now I'm looking for ways to generalize (with the goal of making things simpler for students -- I'm talking about students who can be given a screenshot of a working use of soundfiler, getting frames and SR and using them properly, and literally can't even copy the objects and connections... you'd be amazed how creative they can be at messing it up).

But this seems to require mystical undocumented secrets ("removed from vanilla help..... -86 Million points").

hjh

@whale-av said:

@ddw_music Dynamic patching...... a good place to start (removed from vanilla help..... -86 Million points).
0.all_msg.pd

Woa. It's been a while since I took the time to read this carefully. So it appears that, to add a datastructure scalar to a window, you can

• either do as the reference says, i.e. [traverse window, bang( => [pointer] => [append], etc...
• or send [scalar dataType dataValues( to the window

What a joke.

@kyro The [append] method has the benefit that you directly get the pointer. Not sure if this is still on the thread topic though...

What a joke.

In Purr Data you type the name of the struct in a box and it instantiates the scalar.

you'd be amazed how creative they can be at messing it up

In fairness to your students, due to a historical accident soundfiler's interface is poor. You get a bunch of anonymous values in a single message out the right inlet, and a single value out of the left inlet. For the right outlet it's the user's job to remember the map of attributes to positional arguments and then parse the message to get the positional arguments they care about.

Nobody would ever design the interface that way on purpose. You'd simply send an object to the outlet, like this:

[soundfiler]
|
[get samples type rate etc.]

Now the data would be self-documenting and automatically routed to the appropriate outlet of [get]. (Ignoring for the moment that args and outlets don't line up on objects like [route] and [get].) Also, the interface would be backwards-compatible since adding a new key/value pair doesn't break anything.

However, there would still two problems doing it this way. First, [get] also suffers from an annoying historical accident-- it's first arg is the name of the struct. So you have to add an annoying "-" to stand in for null: [get - samples type rate etc.]

Second, the interface in C for dealing with dictionaries in Pd is even worse than the output interface of [soundfiler]. You can't simply call a function to map a few names to argv data. AFAICT you'd have to define a template, instantiate a scalar, and then manually populate the scalar with the data you want to map. That's too much work just to put names to data, so nobody does it.

There are enough of these problems in the core that when I find myself getting tired of programming in Pd, I'm usually in the middle of doing something low-effort or trivial, like grabbing a value from the middle of a list, or preparing a value downstream for a conditional test. In Javascript or C, I almost always stop due to a mental model of an algorithm not being fully fleshed out, or faulty. (Well, with js there's also stopping due to DOM complexity/edge cases which can be annoying.)

Edit: clarification