phiol

I've been trying to figure out how to use coll to store my data. Since pattrstorage has been crashing max! I will mostly store multislider values. The way I figured out how to do this is;

multislider/value N/coll/back directly in multislider. This seems to work but I have a problem with the coll address. I read in the manual that coll recognizes the first int as the adress (this has been true). So of course when I want to store different slider presets having the 1st slider being of the same value , it replaces the last preset having the same adress.

Another thing, which is weird is that it crunches the multislider values. Say I have 256 sliders doing a visual wave, when fetching back my preset in coll I

will oddly get smaller picture version (but the number of sliders stays the same).

Also, when refetching my presets, the adress being odd random values, I tried using the messages next and previous in association with [counter] which is hooked up to the bang of my [value] object. The point is to make it my adress, in order to fetch back in chronological order.

Anyways, any advice on how to use this coll object to store presets would be greats.

One last thing, when I use (command I) on coll , I have the option to save coll with patcher. Does this mean I do not have to use the flag 0 1 message??

I've been trying to figure out how to use coll  to store my data. Since pattrstorage has been crashing max!  I will mostly store multislider values. The way I figured out how to do this is;

multislider/value N/coll/back directly in multislider. This seems to work but I have a problem with the coll address. I read in the manual that coll recognizes the first int as the adress (this has been true).  So of course when I want to store different slider presets having the 1st slider being of the same value , it replaces the last preset having the same adress.

Another thing, which is weird is that it crunches the multislider values. Say I have 256 sliders doing a visual wave, when fetching back my preset in coll I
will oddly get smaller picture version (but the number of sliders stays the same).

Anyways, any advice on how to use this coll object to store presets would be greats.
One last thing, when I use (command I) on coll , I have the option to save coll with patcher. Does this mean I do not have to use the flag 0 1 message??

simple-questions-about-coll

If pattrstorage is crashing Max, it would be great if you could isolate 

the behavior and provide an example so that it can be fixed.

> I've been trying to figure out how to use coll to store my data. Since pattrstorage has been crashing max! I will mostly store multislider values. The way I figured out how to do this is;

> multislider/value N/coll/back directly in multislider. This seems to work but I have a problem with the coll address. I read in the manual that coll recognizes the first int as the adress (this has been true). So of course when I want to store different slider presets having the 1st slider being of the same value , it replaces the last preset having the same adress.

> Another thing, which is weird is that it crunches the multislider values. Say I have 256 sliders doing a visual wave, when fetching back my preset in coll I

> will oddly get smaller picture version (but the number of sliders stays the same).

> Also, when refetching my presets, the adress being odd random values, I tried using the messages next and previous in association with [counter] which is hooked up to the bang of my [value] object. The point is to make it my adress, in order to fetch back in chronological order.

> Anyways, any advice on how to use this coll object to store presets would be greats.

> One last thing, when I use (command I) on coll , I have the option to save coll with patcher. Does this mean I do not have to use the flag 0 1 message??

If pattrstorage is crashing Max, it would be great if you could isolate 
the behavior and provide an example so that it can be fixed.

phil wrote:
> Hi all
>
> I've been trying to figure out how to use coll  to store my data. Since pattrstorage has been crashing max!  I will mostly store multislider values. The way I figured out how to do this is;
>
> multislider/value N/coll/back directly in multislider. This seems to work but I have a problem with the coll address. I read in the manual that coll recognizes the first int as the adress (this has been true).  So of course when I want to store different slider presets having the 1st slider being of the same value , it replaces the last preset having the same adress.
>
> Another thing, which is weird is that it crunches the multislider values. Say I have 256 sliders doing a visual wave, when fetching back my preset in coll I
> will oddly get smaller picture version (but the number of sliders stays the same).
>
> Also, when refetching my presets, the adress being odd random values, I tried using the messages next and previous in association with [counter] which is hooked up to the bang of my [value] object. The point is to make it my adress, in order to fetch back in chronological order.
>
> Anyways, any advice on how to use this coll object to store presets would be greats.
> One last thing, when I use (command I) on coll , I have the option to save coll with patcher. Does this mean I do not have to use the flag 0 1 message??
>
> thanks alot
>
>
> phil
>


Good decision imo. I use colls nearly exclusively for data storage.

A coll object with two primary keys would come in handy at times, but i'm afraid this is undoable technically, the linked list really doesn't provide for something like that.

Built you a small example of the basic structure. I understand you want to make presets for the multisliders. The way i did this in my patch is to use the index of the coll to store the multislider number as well as the preset number. (preset# * 100 + multislider#). Change the 100 around as you see fit, but do remember that a coll entry can only hold 255 elements)

A lot more functionality (such as fading between presets and such) can be added too, but i won't tire you with any of that :)

A lot more functionality (such as fading between presets and such) can be added too, but i won't tire you with any of that :)
Good luck!

Oh, and i'd definitely be interested in the pattrstorage bug as well. I read in some other thread that a memory leaking issue has been fixed a while ago, and i haven't been able to crash it since (although i haven't spent a great deal of time trying).

But it's probably too much work to change everything back to pattrstorage now anyway, coll really isn't that bad of a replacement. It requires you to make some of the functionality of pattrstrorage yourself but it also provides more control and flexibility (and you don't have to use object names), so it's not all bad.

Oh, and i'd definitely be interested in the pattrstorage bug as well. I read in some other thread that a memory leaking issue has been fixed a while ago, and i haven't been able to crash it since (although i haven't spent a great deal of time trying). 

But it's probably too much work to change everything back to pattrstorage now anyway, coll really isn't that bad of a replacement. It requires you to make some of the functionality of pattrstrorage yourself but it also provides more control and flexibility (and you don't have to use object names), so it's not all bad.


Sure, I understand that. My point is more that offhandedly mentioning 

that 'xxxx crashes Max' doesn't help anyone, whereas taking a little 

time to prepare and submit support requests is useful all around. We 

don't ever ship software with known bugs, so if you're having a problem, 

we probably don't know about it! Let us know...

> Oh, and i'd definitely be interested in the pattrstorage bug as well. I read in some other thread that a memory leaking issue has been fixed a while ago, and i haven't been able to crash it since (although i haven't spent a great deal of time trying). 

> But it's probably too much work to change everything back to pattrstorage now anyway, coll really isn't that bad of a replacement. It requires you to make some of the functionality of pattrstrorage yourself but it also provides more control and flexibility (and you don't have to use object names), so it's not all bad.

> Hard- and software for interactive audiovisual sampling

Sure, I understand that. My point is more that offhandedly mentioning 
that 'xxxx crashes Max' doesn't help anyone, whereas taking a little 
time to prepare and submit support requests is useful all around. We 
don't ever ship software with known bugs, so if you're having a problem, 
we probably don't know about it! Let us know...

Bas van der Graaff wrote:
> Oh, and i'd definitely be interested in the pattrstorage bug as well. I read in some other thread that a memory leaking issue has been fixed a while ago, and i haven't been able to crash it since (although i haven't spent a great deal of time trying). 
>
> But it's probably too much work to change everything back to pattrstorage now anyway, coll really isn't that bad of a replacement. It requires you to make some of the functionality of pattrstrorage yourself but it also provides more control and flexibility (and you don't have to use object names), so it's not all bad.
> --
> SmadSteck - http://www.smadsteck.nl
> Hard- and software for interactive audiovisual sampling


Now I think I'm even more confused. I spent some time trying to understand you patch (by the way thanks for the generosity). But it has got me more confused ! And also what does imo stand for ?? I am not a literal type of person , but when learning max on my own I have to take everything into account!! Below is your patch with all of my questions. And has my version of your patch indicates, I don't know C language.

Subject: New reply to Re: simple questions about coll by Bas van der Graaff

Subject: Re: simple questions about coll     Author: Bas van der Graaff     Date: Thu, 06 December 2007 16:12

Hi Bas,
Now I think I'm even more confused. I spent some time trying to understand you patch (by the way thanks for the generosity). But it has got me more confused ! And also what does imo stand for ?? I am not a literal type of person , but when learning max on my own I have to take everything into account!! Below is your patch with all of my questions. And has my version  of your patch  indicates, I don't know  C language.

thanks a lot for your efforts
Hope to hear from you soon

    Date: Thu, 6 Dec 2007 16:12:58 +0100
    To: philippehughes@hotmail.com
    Subject: New reply to Re: simple questions about coll by Bas van der Graaff
    From: loadbang@cycling74.com

    Subject: Re: simple questions about coll 	Author: Bas van der Graaff 	Date: Thu, 06 December 2007 16:12
    Good decision imo. I use colls nearly exclusively for data storage.

    A coll object with two primary keys would come in handy at times, but i'm afraid this is undoable technically, the linked list really doesn't provide for something like that.

    Built you a small example of the basic structure. I understand you want to make presets for the multisliders. The way i did this in my patch is to use the index of the coll to store the multislider number as well as the preset number. (preset# * 100 + multislider#). Change the 100 around as you see fit, but do remember that a coll entry can only hold 255 elements)

    A lot more functionality (such as fading between presets and such) can be added too, but i won't tire you with any of that :)
    Good luck!

You can simply "prepend #" before saving the multislider into the coll, so it will have whatever index you want. Try this:

Thanks a lot for the patch. This is exactly it! Although, this is exactly what I thought I did before first posting on the forum. I am suprise to se that coll does not react like a message box! (Or am I mixing things up?). What I had done was have multislider into [value N].[prepend $1,]-- [set ]and was testing it with a message box. But then I couldn't get the N,

Anyways, I've adjusted your patch with a sort of gate for the multi and N box with an [int] and [value N] hooked to bang , so that I can decide on when multi values are entered.

One last question. Does having a message [set $1] replace the argument 1 in [prepend 1]. Why not have [prepend set $1]. And does [coll] automatically add a comma when a [prepend N] is hooked up to it?

Many many thanks for helping me learn this wonderful software.

Thanks a lot for the patch. This is exactly it! Although, this is exactly what I thought I did before first posting on the forum. I am suprise to se that coll does not react like a message box! (Or am I mixing things up?).  What I had done was have multislider into [value N].[prepend $1,]-- [set ]and was testing it with a message box. But then I couldn't  get the N,
Anyways, I've adjusted your patch with a sort of gate for the multi and N box with an [int] and [value N] hooked to bang , so that I can decide on when multi values are entered.

One last question. Does having a message [set $1] replace the argument 1 in [prepend 1]. Why not have [prepend set $1]. And does [coll] automatically add a comma when a [prepend N] is hooked up to it? 

I did send you an isolated part of my patch, that making my max. Did you get it?

Now I'm realiszing that maybe I've been sending everything to the wrong place GOD!! 

Now I'm realiszing that maybe I've been sending everything to the wrong place GOD!! 
Sending all to loadbang@cycling74.com
sheesh!

Glad things are working for you. Yep, the coll will add the comma by itself, it's to isolate the index number from the data. Likewise it takes it away (and the index number) when you access the data.

The question about the "prepend" is *sort of* straightforward, but I'd take another look at the message and prepend help files... I often make mistakes with the differences. You can prepend and append using a message box, but also with the prepend object... and there's *some* overlap as to what they can do. Really though you're generally going to be OK with the object rather than the message box, but the message version works for certain stuff. It also takes the $1 argument, whereas the object doesn't. That's why you want the "set $1" going into the prepend -- it holds the value and waits for data in (multislider list in this case) and sticks the number in front as an index.

Try this new patch -- it has a pattr version, see if it still crashes your machine?? Also it has *mtr* which is a great object to know about. In this case it records how you access your pattr presets... so one changing number recalls whole lists of interpolated data, and the changes you make can be played back. Very powerful possibilities when used like this, as you might imagine (think multi as lists of velocities, pitches, brightness levels, speed of playback over time, access to other multis, etc. etc... all of which can be accessed whenever you want, either the whole list at once out the left outlet, or use the fetch $1 message for single sliders out the right.)

This is a totally simple mtr, there are other options for variable-rate playback, etc. (like seq, seq~, or there's a trick to doing it with a single-element mtr, by using "next" and delays instead of "play".)

------------------------------------------

Try this new patch -- it has a pattr version, see if it still crashes your machine?? Also it has *mtr* which is a great object to know about. In this case it records how you access your pattr presets... so one changing number recalls whole lists of interpolated data, and the changes you make can be played back. Very powerful possibilities when used like this, as you might imagine (think multi as lists of velocities, pitches, brightness levels, speed of playback over time, access to other multis, etc. etc... all of which can be accessed whenever you want, either the whole list at once out the left outlet, or use the fetch $1 message for single sliders out the right.) 

WOW! CJ ! that's amazing stuff ! The possibilities.

I totally agree, I've been doing nothing but in the past few months.

Your second patch set up involving pattr and mtr has not been making my max crash although I have not intergrated it to my master patch that was making max crash.

I will definately further explore this mtr object. Where and how are your actions recorded??

Again, thanks a lot every time you've replied, I move from a max plateau. Unclogging the clusters of questions

>Warning: Max is very addictive.
I totally agree, I've been doing nothing but in the past few months.

Your second patch set up involving pattr and mtr has not been making my max crash although I have not intergrated it to my master patch that was making max crash. 

I will definately further explore this mtr object. Where and how are your actions recorded?? 

Again, thanks a lot every time you've replied, I move from a max plateau. Unclogging the clusters of questions 

The mtr records only one sequence at a time, but up to 32 tracks (see help file). It's just a text list of "track #" and "duration" and "value" for each track. You can write and read these files back into your mtr for use whenever. It *won't* do lists (except some particular ones like the RGB of Swatch)... you have to unpack them and record individual tracks. Look into seq~ too: only a few tracks, but variable-rate playback and multiple sequences at once, yum.

Hope the pattr continues to work, it's really amazing what it can do... there's also other kinds of interpolation available besides linear (default). It's fun just to watch the multisliders, without them even doing anything, heh. When you start thinking of your values and lists as abstract, where they can control anything you want, the possibilities really start to multiply (this can be a blessing and a curse). Experiment a lot but try to eventually limit yourself to a direction, and you'll have better chances of getting a patch done that you use a lot rather than having it collect dust... most of mine do this, argh. ;)

Hope the pattr continues to work, it's really amazing what it can do... there's also other kinds of interpolation available besides linear (default). It's fun just to watch the multisliders, without them even doing anything, heh. When you start thinking of your values and lists as abstract, where they can control anything you want, the possibilities really start to multiply (this can be a blessing and a curse). Experiment a lot but try to eventually limit yourself to a direction, and you'll have better chances of getting a patch done that you use a lot rather than having it collect dust... most of mine do this, argh.  ;)

i am obsessed with utilizing my mouse to control a majority

of things in my patch. i would like to use the lcd to

control rapid fire samples, which i would further

Here is a midi example of the gist i would like to do, but

i want the lcd to trigger samples via buffer~ (which i also

http://tools.search.yahoo.com/newsearch/category.php?category=shopping

i am obsessed with utilizing my mouse to control a majority
of things in my patch.   i would like to use the lcd to
control rapid fire samples, which i would further
manipulate in real time

Here is a midi example of the gist i would like to do, but
i want the lcd to trigger samples via buffer~ (which i also
use alot).

Any help would be appreciated.  Thanks!
-chuck 

Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  http://tools.search.yahoo.com/newsearch/category.php?category=shopping


some ideas... you'll have to get into the MSP objects to manage samples. I listed some of them in the patch. The LCD control idea is pretty cool; you could also use a pictctrl and customize the appearance if you want.

I completely agree with you on avoiding the dust collection. That's why I must absolutely have a weekly music project going on with other people. It forces me to make decisions on what to keep and not , and when testing an idea with a band, you see right away what needs to be change for effeciency in live situations. Otherwise I'm screwed.

Thanks a lot for your time. I really recognize your effort.

hi cj
thanks for more insights. 
I completely agree with you on avoiding the dust collection. That's why I must absolutely have a weekly music project going on with other people. It forces me to make decisions on what to keep and not , and when testing an idea with a band, you see right away what  needs to be change for effeciency in live situations. Otherwise I'm  screwed. 

Sorry for not replying earlier, i was away. I think jln did a pretty good job there, thanks.

I mistakenly thought you were also planning to use multiple multisliders (or even different gui elements), which would be possible with my example.

But Seejay's example does fine as well...

Sorry for not replying earlier, i was away. I think jln did a pretty good job there, thanks. 

But Seejay's example does fine as well...


No I know, your patch is great and I will study it further to attain more possibilities.

> (and you don't have to use object names), so it's not all bad.

But the automatic object naming and navigation through the patcher 

hierarchies is the best about the pattr system. Can't live without it, 

Must have been a pain to get this functionality put into colls...

I guess its even less pain to learn the pattr system than just 

To add a parameter I want to store in a preset, I don't need to patch 

anything, just give it a name - how do you do that with colls?

Bas van der Graaff schrieb:
> (and you don't have to use object names), so it's not all bad.

But the automatic object naming and navigation through the patcher 
hierarchies is the best about the pattr system. Can't live without it, 
use it all over the place...
Must have been a pain to get this functionality put into colls...

I guess its even less pain to learn the pattr system than just 
maintaining a selfmade one...

To add a parameter I want to store in a preset, I don't need to patch 
anything, just give it a name - how do you do that with colls?

-- 
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com


> To add a parameter I want to store in a preset, I don't need to patch 

> anything, just give it a name - how do you do that with colls?

But I have something against object names - it's probably because you cannot see them at a glance. Wouldn't it be useful to hold some keyboard key and see all object names?

The only other thing i have against pattrs are their speed (you probably read the oo thread). For example, when interpolating between 2 stores in my coll i can generate a list of the ones that actually change value and only update those. Especially when using lot of ui objects (some of which jsui) , this makes for a big speed increase. Also, just getting values to process them but not updating my gui at all is a lot easier.

Pattrstorage nearly has everything i want it to, but not quite. But maybe i should re-evaluate at some point...

>
> To add a parameter I want to store in a preset, I don't need to patch 
> anything, just give it a name - how do you do that with colls?
>
> Stefan
>