based on my last post ("universal bus") i worked further to find a way, how to convert audio to a samplerate synced floatstream. this means, you can send an audio signal via a message cord, transformed to a floatstream.
you may ask: for what?
well, you can then use different message objects (or whatever) to edit the audio signal before you convert it back to audio, and then send it to the [dac~].

i always searched for a [tabwrite~] object, that was capable of accessing single indicies of an array. but tabwrite~ doesn't feature this, because audio is processed in blocks in pd.
but the message domain [tabwrite] can do this. so now you can use [tabwrite] to process audio too.

or maybe you want to create your own oscillators from scratch. this all is possible with a sample rate clock, like the one, used in this patch here.

just don't know what you folks think about that, but for me, this is a gate to a new world.

http://www.pdpatchrepo.info/hurleur/audiostream_converter.pd

Interesting. I'd be interested in seeing some examples of things that you can do in the message domain and not the audio domain.

Btw, you might be interested in [poke~].

uhhh, did i have my eyes closed over the years? that's a bit disappointing.
the issue with pd is to find the object that suits your needs, when you need it. there it's hard to keep track of all the external out there.

well, don't you think that there would be applications, you could use audio converted to floats or lists or whatever? i mean, you could use all the list objects and abstractions?
now, i will see... maybe i've mistaken!?

@toxonic said:

just don't know what you folks think about that, but for me, this is a gate to a new world.

Though I have seen [unpack~] and [pack~] sometimes in other peoples patches I was never aware of it's potential, until you mentioned it.

You could do very weird one-sample feedback delay stuff, for example. Or find sample-precise cuepoints for transients. Or find a maximum in a signal vector before processing it. Things you'd normally do in C. You're right, this opens a world of possibilities.

Happy you came up with this topic.

Katja

@katjav said:

You could do very weird one-sample feedback delay stuff, for example.

I was just out on a walk and thought of this. Some filters can't be made with [rpole~] et al. or using a [block~ 1]. This method gets around that. Though I wonder if it's any more or less cpu intensive...

by the way, i found a much more cpu efficient way to convert audio to a sample accurate floatstream, like this:

[inlet~] <--- signal in
|
[pack~]
|
[drip <delay>] <--- where <delay> is 1000 / samplerate~
|
[outlet] <--- message out

cheers