Is [openfoldercoll] an abstraction you have made or an external? If it is an external could you say where to find it so understanding your patch would be easier.

lh

Wow , i totally forgot about that , sorry ..

Its an abstraction

here is the code :

Thanks

Greg

And a last thing , openfoldercoll doesn't work when there are spaces in the path , i forgot to fix this .

cheers

G

There's a few things I've noticed. First of all in your [openfoldercoll] subpatch you need to insert a [tosymbol] between your absolute path and the [pack] object otherwise if there is a space in the path it will not store correctly in the [coll].

Other than that your main problem seems to be the order that you trigger events. For example the [sprintf] that sends the "replace" message is receiving the send destination before the file path from [coll]. It should be the other way around because the left inlet triggers the output not the right. You will definitely want to study the benefits of the [trigger] object a bit more. I would advise you to make a written flow chart of what you want to happen and in what order and then set about trying to rebuild your patch using that as a guide.

I thought your problem was quite interesting so I have designed my own method from the bottom up. It works pretty well so far. If you want to have a look at it then let me know. I use max 5 so if you're still only on 4.6 I could perhaps post a screenshot for you to work from.

lh

Sorry for the delay man and thanks for you valuable insight, but i was working yesterday till late. I tried your suggestions , but i must still be doing something wrong with the triggering of events. I will post it when it (hopefully) works :) I would be interested to see your approach , since i am not sure even when i fix this that it might be the best way to achieve what i need.

Basically this is supposed to work with an granular patch , where i will be controlling which sound buffer will access each grain stream . For that i need also the duration , as well as start and end points for segments of the audio files that will be granulated .

I was wondering thus if this is the best way to do so , because i am not sure about how i can access these start and end points . In the beginning i thought that i could mark this points into an audio editor (instead of using waveform~ , which would be tricky when the number of audio files is high), but i am not sure whether these points can be imported in a buffer .

cheers

Greg

Ah I just emailed you to see if you'd managed to fix your patch. Here are my methods which seem to work just fine.

Will you be connecting directly to these buffers or refering to them elsewhere in the patch? I'd suggest refering to them from elsewhere as this means less scripting and you can also look at my [poly~] approach. Will you need the lengths of all files all the time (stored in a [coll] perhaps?) or just find the length of a particular file when you use it?

Anyway, below is the scripting approach which names the [buffer~]s after the file you loaded into it. Below that is another patch which uses [poly~] to load the sounds without worrying about scripting and below that is the extremely simple [poly~] abstraction which should be named "autobuf". Let me know if you have any problems using them or understanding what's going on inside.

lh

Scripting:

Non-scripting:

Poly:

Yes i received your email thanks ,

Unfortunately i can't open the solution you posted since i am in max 4.6

I managed to fix the biggest part of the patch , you were right there was a mix up with the order of the events . The problem was though not only in the generatebuffers abstraction but also in the "openfolder" abstraction .

It seems that the folder object sends its output from left to right , i spent at least an hour trying to see what was going on. Because basically i was sending the replace message before filling the coll .

However i still haven't fixed the issue when there is a space in the path(not a big issue since i have the habit of using underscores in the folders , still..) .

As for the granulation patch , i still need to make a choice on how to work with multiple buffers. The version i have now is accessing only one buffer . So what i do is open a sound file , select a region with waveform~ , calculate it's duration , divide this with the grain size thus getting the number of grains per region . Then when granulating i can choose if i want to repeat each grain a number of times, play with their order, etc .

I am not sure though if this would be a good strategy with multiple buffers. Perhaps i should "prepare" the files first in an audio editor, and forget the waveform~ object .

So to answer your question ,since i plan to basically mix up grains (scholastically) from various sound files , i need the buffer names and durations to be stored in a coll immediately .

From this coll i can make a new one with buffer names and grains per sound file which is actually the one i'll be using for the granulation. The granulation patch uses the play~ object to read through the grains , thus i am referring to them by name , not connecting to them .

I'll post you the folder patch so far , if you are interested i can also post the granulation patch although probably basic .

I was wondering though , if there is a way to retain loop points created in an audio editor . This could be a nice compromise between the two strategies .

thanks a lot

Greg

name as "openfoldercoll"

name as "generatebuffers"

and the main patch :

I have taken out the generate info~ part at this point , at least until i solve the issues with the spaces , since it seemed to work fine .

To understand paths with spaces you need to make sure that the collection and the "replace" message receive the file path as one symbol which can be done using [sprintf "%s"] or some such variation thereof, it's including the "quotes" that makes all the difference. I had to do this to get it working as my hard drive is called "Macintosh HD".

lh

OK i found some time to work on it more , and this time it works . It is though quite ugly:) The problem with the spaces still remains though, i tried your sprintf suggestion but it doesn't seem to work when there are several spaces , also i used the tosymbol and fromsymbol objects still without success . Nevertheless now i can open a folder load the wave files into buffers and create a coll with the buffer names and the corresponding durations , to access elsewere . There is still some polishing needed but i think for the moment it will do .

Still it would be nice to see your approach , i don't know if you cold post some screen shots , in any case you have been very helpful and I'd like to thank for that .

Below is the patch :

save as "openfoldercoll"

save as "generatebufandname"

and the main :

Here's the two approaches I mentioned before, one using scripting to [thispatcher] like your patch and one using [poly~]. I added on the [coll] bit you mentioned so it should store the full filepath and time as well. I think all the objects are standard in 4.6 so you shouldn't have much trouble piecing the patches back together from the screenshots. If you get stuck feel free to message me.

lh

http://tinyurl.com/5drlqy