I'm wondering if there is a way to load a folder of audio files (to be read by [ readsf~ ]) into a Pd patch without having to specify all the filenames within the patch first. Possibly even through drag-and-drop?

@RonHerrema That means that the object [s trackplay is either missing, or existing twice in the playlist window. I just downloaded it and it works fine here, so I have put in a small delay to make sure that the object is created.... see if that works... if not then I will have to look further......
cart.pd
David.

That works beautifully, David - many thanks!

This is tangentially related, but do you know why Pd (extended, at least) is so slow in responding to mouse clicks when Apple dialog boxes are open? This has always been the case for me.

cheers

Ron

@RonHerrema Hello again Ron....... it might not be so tangential...........
I am using windows so I cannot be certain. Usually if Pd is struggling, then it is audio related. Pd gives priority always to audio, which makes sense, but the smallest problem can mean that the other work doesn't get done, or at least not very quickly..........
So........
is the slowness Pd patch dependant, or always the case?
what exactly are these dialog boxes....... are they Pd drop down menus? or something else?
is your Pd audio setup matched well to the audio settings for your Mac?
...... if you turn off dsp in Pd, does the problem disappear?
David.

Thanks again, David. Those are good questions. Generally speaking I would say that it's 'always the case', though not universally so, and I notice that today with the same patch it seems to be faster. I'll continue to pay attention to the various issues you've mentioned.

I see that your patch doesn't work with Pd-vanilla. Is there a way to make it work using externals? (I guess that implies you'd have to code the externals in C.)

cheers

@RonHerrema Hello Ron....... for externals I am not your man.....
The parts that are not vanilla friendly are the [tof/folderpanel] and [ext13/strippath] objects. They make it "universal" for the file paths.
If you constrain your folder choice to a subfolder of that containing your patch then you can just send the track names from a list (a text file) that you could open in your patch concurrently (see the [open/tracks/$1( message that is at the left side of the patch). It's not so elegant, and no easier.
David.

Got it - thanks for all the prompt and clear explanations.

R.

I"m back. What I would like to do at this point (this can be pd-extended) is to load a folder of file (names) and to play them back (using an arbitrary key press) in random order, displaying the name of the currently playing file. This is assuming the number of files in the folder is unknown in advance, and that the path of the folder is unknown in advance. I assume there must be a way to connect a random number generator to all these message boxes on the fly, but I haven't figured out how to do it.

Well, I'm starting to get the hang of it - it seems that it's important to send 'clear' before making objects and connecting.

@RonHerrema Hello again Ron......
Are you planning to have a main folder, with sub-folders all containing tracks, or are you expecting to just pick folders at random from anywhere on your computer.
If you want to pick from absolutely anywhere then you have three problems....
Most folders will have no wav files.........
Some folders will have wav files at the wrong sample rate....
Most folders containing wav files will contain other files as well... album art, etc.

Anyway..... in "cart" the playlist window is cleared and re-populated as each folder is opened.
If you want to bang a message box you need to give each one a [receive] object and then build a patch to send bangs to those objects. That patch is easy using [random]. The track name will always display in "cart" already. The number of tracks can be known (already the tracklist populator stops when it has created the messages in tracklist).
So you need to add (using the populator) a receive object for each message, place it into "tracklist" and attach (connect) each one to its message.

Either you should do this.........
The populator creates the message, connects it to the [s trackplay] object, creates the [receive 1] object and connects it to the message........ and moves on.
Or this....... the populator runs as in cart, but you add a counter, and when it has finished (how do you know, do you just put a delay and hope) it builds the [receive objects and connects them.

I reckon the first is easier. [s trackplay is object 0 on the page and each message is 1-n for the connect message. You need to change the numbers for the connect messages.......
the populator will build..
[s trackplay] (this is object 0)
[message 1] (this is object 1)
connect object 1 to object 0
[receive 1] (this is object 2)
connect object 2 to object 1
[message 2] (this is object 3....... in "cart" it was object 2 but [receive 1 has been created first)
connect object 3 to object 0
[receive 2] (this is object 4)
connect object 4 to object 3
etc. and it will stop when no more names arrive.

You will need a counter though (don't forget to reset it when the next folder is loaded) so that random can have the right argument. [random x].

You can use the right outlet of [readsf~] to bang out the next number from [random] and start the next track..............another counter and a calculation (when tracks played == track count +1) load the next folder.......... etc.......
Have Fun!
David.

@RonHerrema That was a bit of a mouthful composed on my return from the pub........ but it is correct I think.

Now that you have understood it all........ here is the easy way to do it......
The patch tracklist_button.pd is called by the propagator for each track, and given two arguments........ the track name, and it's number in the list. It is what is called an "abstraction".
Now all you have to do is send your random number to "playit" using [s playit]
cart2.pd
David.

Once again, many thanks. I am getting error messages:

tracklist_button Track 01 Almost Like the Berlin Wall.aiff 1
... couldn't create
tracklist_button Track 02 Private Property No Trespassing.aiff 2
... couldn't create
tracklist_button Track 03 Steal the Common from the Goose.aiff 3
... couldn't create

I should probably mention that I actually don't want to see the list of sounds, though I guess that is fairly easy to control through the 'vis' command? I only want to see the currently played sound displayed. I'm going to upload here the patch of my own that I'm trying to integrate this with. You'll see it's built to load just one file for each of the five buttons, so what I"m trying to do is to change it to load folders, and to display the name of the currently playing file (triggered randomly with the first five number keys) just below the current symbol object. For simplicity's sake, I'll just ask the user to type in the folder name into the current symbol objects you see there.

slow_down.pd

@RonHerrema Sorry Ron... I didn't post the abstraction........ Alzheimer's?
cart2.zip
The currently loaded sound is displayed in the main cart window.
I will look at your patch tomorrow...... , its bedtime.....
David.

Thanks - of course, with the abstraction it works. I've combined a large portion of your patch with mine. You'll see that I use alternate presses of the key to start and then fade out. The main problem I have at this point is that I have five copies of this sub patch, but there's just one abstraction, so I'm not sure how to deal with individualising the names. I don't totally grasp how to use $0.

slow_down_david.pd

@RonHerrema Ok....... head spinning!.........
slower.pd is your patch, but I have made your "pd-playback" into playback_module.pd so it is now another abstraction and you can put as many as you wish (and edit only one copy for any changes that you want to make).
So I have put [playback_module 1] and [playback_module 2]...... The argument.. the 1 and the 2 are then used so that playit-$1 becomes playit-1 (or playit-2 for the second one) and the same for trackplay......... so now the two "instances" are different.
The argument has then been sent through to all of the "tracklist_button" objects ($3) so that they can respond only to the patch that created them, and there is an individualised "tracklist" for each set.
You could incorporate your meters within "playback_module". Your send and receive objects will need to incorporate identifiers as well ($1) and I might have missed one or two so please check....... but it's a start......
$0 is not so useful, because other parts of your patch don't know its value and cannot "talk". It is useful to differentiate abstractions where they can talk internally through $0, but to their "outside world" it is easier to use $n in messages, and the [inlet] and [outlet] objects..........
cart3.zip
You can then put [playback_module 3] ......etc....... if you wish.
Remember that if you edit [playback_module] and save and reopen your patch you have changed every copy......... usually an advantage, but not always, which is why I have left the playbacks 3,4 and 5 alone for now........
David.

http://bitsynthesis.com/assets/downloads/pd/rand_file.pd

Your head spins quite well, David! This works beautifully. Now that I use it, I can see that my original plan to have the user type in the folder name is not optimal, because there is no visual feedback given when the folder has been loaded. I did a bit of research about how to isolate a folder name from a path, but it's still not clear to me if it's doable ([strippath] and [stripfilename] won't work, for example). Is it??

heyok, thanks. I've been playing with your patch but don't yet understand how to implement it. I've tried the following, but it doesn't work:

[bang]
|
[tof/folderpanel]
|
{symbol]
|
{makefilename %s/*.aif]
|
[rand_file]

[bang(
|
[tof/folderpanel]
|
[symbol $1/*(
|
[rand_file]

@RonHerrema Hello again Ron........
Here is the last zip with the folder name added to the "playback module"......
cart4.zip
[strippath] outputs everything following the last / in the symbol that it is "given"...
I hope that is what you are looking for.......
David.

Thanks, David - that was way too easy. And yes, that is what I was looking for.

Cheers