Forums > MaxMSP

Save buffer~ content using pattrstorage like solution

January 18, 2009 | 4:57 pm

Hi
i’m using a nested autopattr and pattrostorage to save presets for a big patch i’m using for live performances. I didn’t figured out yet however how to include the audio files currently loaded in the buffers in the storing system. To be more clear, i need to include the current buffer content in a preset in order to change the buffer content when the preset is recalled using the pattrstorage system.
I think buffers are not exposed by the autopattr system, as i can’t see the buffer objects in the pattrstorage clients list.
thanks
greetings
Fabrizio


January 18, 2009 | 5:40 pm

My guess is that you don’t want to save the contents of a buffer as the
preset but something that points to the file that loads into the buffer when
you recall a preset, like the filename? You would then be looking at
storing the filename for the file you load into the buffer using the replace
message. You could do this by attaching a pattr to the object that you use
to invoke the file to be loaded, eg a umenu.

On the other hand, if you do want to store the contents of a buffer in the
pattr system you can do so by filling a pattr with a list of values that
represent each sample of the buffer, which you can get using a peek~ object.

You need to provide more information for a more specific answer

pelado

http://www.pelado.co.uk

http://www.wiki.pelado.co.uk

On Sun, Jan 18, 2009 at 5:57 PM, Fabrizio wrote:

>
> Hi
> i’m using a nested autopattr and pattrostorage to save presets for a big
> patch i’m using for live performances. I didn’t figured out yet however how
> to include the audio files currently loaded in the buffers in the storing
> system. To be more clear, i need to include the current buffer content in a
> preset in order to change the buffer content when the preset is recalled
> using the pattrstorage system.
> I think buffers are not exposed by the autopattr system, as i can’t see the
> buffer objects in the pattrstorage clients list.
> thanks
> greetings
> Fabrizio
>


January 18, 2009 | 7:33 pm

Hi pelado,
thanks for your kind reply.
Actually i don’t want to store the "buffer data" but just the filename, so that i can recall it when the preset is loaded. I thought that buffer~ could expose the filename as a autopattr client and was missing something… anyway this seems not to be the case.
I load the audio clips by dragging in the file from the browser on a drag-and-drop box that stands over the waveform~ showing the buffer,and the d&d out goes into a replace $1 message.
I think i could do that without getting "dirty", but i think i’ll store the filenames in a coll or a umenu as you suggested.
thanks again for your time
greetings
Fabrizio


January 18, 2009 | 8:04 pm

Hi, there are two ways I’ve used, use a UMenu to store names of an entire folder of sounfiles and just give the UMenu a scripting name thus exposing it to your autopattr.

Another way would be to use a "textedit" object. Have it set to the path of the soundfile whenever you load it in. Make sure the textedit object has a scripting name to expose it to your autopattr. Save the setup to a preset and next time you recall the preset, the file-path will be loaded via the textedit object.

Here’s the textedit solution because it’s more simple but the UMenu solution is really sharp and besides, you probably want a UMenu for all your files so you can select them song by song for a complete uninterrupted set so definitely look into it. Anyways, here’s the textedit solution:

– Pasted Max Patch, click to expand. –

January 18, 2009 | 8:12 pm

Oh, and about the Umenu object, the preset will actually be storing the menu-item number not the file-path(this should be o.k. if you have everything you’ll ever use in the same folder for a particular performance, that way everything is available in the one UMenu). Sometimes, I don’t even add the scripting name to the umenu but rather a number object that is set by the UMenu and then outputs that same number back into the UMenu whenever the appropriate preset is recalled(the set message prevents a feedback-loop/event-overflow as well). This also allows me to have a gate whereby I can turn off the recall of the soundfiles if I want the preset to apply to everything BUT the soundfile(there are other ways to do this as well). Simply put, the UMenu technique offers for many flexible options, whereas the benefit of the textedit technique is that it is simple, straightforward, and completely transparent to the interface(the user never sees it, it is automatically set when a soundfile is loaded, and the user only uses it when the preset is recalled).


January 18, 2009 | 9:00 pm

Alternatively, if you want to query the content of the buffer~ you can use
the info~ object and feed that to the pattr.

raja, you can store symbols in a umenu using the pattrmode attribute, (but I
don’t think you get the prefix into the pattr).

pelado


January 18, 2009 | 9:15 pm

ah that’s true, in that case, since the folder might remain the same, you could setup some other way to store the prefix. so many options…


January 19, 2009 | 12:26 am

thanks for all your answers. I ended up using the umenu-prefix solution with autopopulation. It’s better for my needs…
thanks again
bye


January 19, 2009 | 10:04 am

On 18 janv. 09, at 17:57, Fabrizio wrote:

> i’m using a nested autopattr and pattrostorage to save presets for a
> big patch i’m using for live performances. I didn’t figured out yet
> however how to include the audio files currently loaded in the
> buffers in the storing system. To be more clear, i need to include
> the current buffer content in a preset in order to change the buffer
> content when the preset is recalled using the pattrstorage system.
> I think buffers are not exposed by the autopattr system, as i can’t
> see the buffer objects in the pattrstorage clients list.

You can save the file path of the sound with a [pattr] instance.
Something like :
[opendialog sound] -> [pattr mysoundfilepath] -> [prepend replace] ->
[buffer~]

_____________________________
Patrick Delges

Centre de Recherches et de Formation Musicales de Wallonie asbl

http://www.crfmw.be/max


June 24, 2009 | 5:56 am
Patrick Delges wrote on Mon, 19 January 2009 03:04
On 18 janv. 09, at 17:57, Fabrizio wrote:

Something like :
[opendialog sound] -> [pattr mysoundfilepath] -> [prepend replace] ->
[buffer~]

I tried this, but the replace message accepts only a filename without extensions, not a filepath. The replace message is important because it is the only message which will resize the buffer upon loading. Anyone got any clues how to do this ?


June 24, 2009 | 6:19 am

The "replace" message does accept a full filepath as an argument. Make sure that if the path is represented as a symbol if it contains spaces.

lh


June 24, 2009 | 6:34 am
thereishopeforus@hotmail.com wrote on Wed, 24 June 2009 00:19
The "replace" message does accept a full filepath as an argument. Make sure that if the path is represented as a symbol if it contains spaces.

lh

so is it an invalid symbol is my filepath contains spaces anywhere ?
firthermore, will I have to strip away the "" symbols from the output of the [opendialog] box?


June 24, 2009 | 6:37 am

If it contains spaces you need to enclose it in quotes like so:

replace "Macintosh HD:/Users/me/files/fileone.aif"

This should be done automatically if you’re using [opendialog], you should just need to send it through a [prepend replace].

lh


June 25, 2009 | 3:12 pm

Try this patch, I made it recently. Be sure to open and close it once before using it to create the xml file.

– Pasted Max Patch, click to expand. –

July 2, 2009 | 10:22 pm

though my motivation is different, i have the same question as the subject suggests (saving the buffer contents rather than the file name).

i just discovered the buffir~ object and would like to have a way of not only storing the contents of a buffer and recalling them, but interpolating between two presets as pattrstorage does so gracefully.

i haven’t yet tried doing this with peek~s and whatnot, but it seems like that would be totally roundabout and unnecessarily computationally intensive.

any ideas?

edit –
ok, so i got peek~ to store values in the pattrstorage properly, but recalling them back into the buffer is another story… to store the list, i had to run it into a pattr object directly (cause zl’s dont get stored??).. it’s looking like i’ll figure it out before anyone replies, but oh well.

edit 2 — nvm, stupidly probing the wrong outlet of pattr. duh.

edit 3 — got it working, albeit a bit slowly…

– Pasted Max Patch, click to expand. –

Viewing 15 posts - 1 through 15 (of 15 total)