Stefan Tiedje

I just loaded a textfile into coll which contained close to 50000 

entries of prime numbers. It would display the following in the Max window:

I just loaded a textfile into coll which contained close to 50000 
entries of prime numbers. It would display the following in the Max window:

coll-limits-maybe-cosmetic

> I just loaded a textfile into coll which contained close to 50000 

> entries of prime numbers. It would display the following in the Max window:

My original emssage seemed to have been cut...

I want to add, I just loaded 1 million lines of prime numbers into a 

coll and it seems to be happy, only the report of how many lines have 

been loaded seems to be off... (And to load a text file of several MB 

will take some time as well..;-) This is pretty amazing. It does slow 

down the computer, though I can't measure it with a timer, the visual 

feedback I get is maybe half a second behind when recalling...

Stefan Tiedje wrote:
> I just loaded a textfile into coll which contained close to 50000 
> entries of prime numbers. It would display the following in the Max window:

I want to add, I just loaded 1 million lines of prime numbers into a 
coll and it seems to be happy, only the report of how many lines have 
been loaded seems to be off... (And to load a text file of several MB 
will take some time as well..;-) This is pretty amazing. It does slow 
down the computer, though I can't measure it with a timer, the visual 
feedback I get is maybe half a second behind when recalling...

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


On 21-Jul-2006, at 12:08, Stefan Tiedje wrote:

>> I just loaded a textfile into coll which contained close to 50000 

>> entries of prime numbers. It would display the following in the 

coll's source code is published with older SDKs. You should be able 

void coll_fromtext(t_xcoll *x, t_handle han, long size)

At the time coll was first written, it was probably reasonable to 

assume that a coll file would not contain more than 32,767 lines. The 

issue is indeed cosmetic. However, if you have an error in the 

999,999th line, the error message will be a little unhelpful.

Peter Castine +--> Litter Power & Litter Bundle for Jitter

Interface Building for |home | chez nous|

Max/MSP Extremely cool |bei uns | i nostri|

On 21-Jul-2006, at 12:08, Stefan Tiedje wrote:
> Stefan Tiedje wrote:
>> I just loaded a textfile into coll which contained close to 50000  
>> entries of prime numbers. It would display the following in the  
>> Max window:

coll's source code is published with older SDKs. You should be able  
to find the cause there.

void coll_fromtext(t_xcoll *x, t_handle han, long size)
{
   long onset = 0;
   char symout[256];
   short line,aCount;
   ^^^^^

At the time coll was first written, it was probably reasonable to  
assume that a coll file would not contain more than 32,767 lines. The  
issue is indeed cosmetic. However, if you have an error in the  
999,999th line, the error message will be a little unhelpful.

--------------    http://www.bek.no/~pcastine/Litter/    -------------
Peter Castine             +--> Litter Power & Litter Bundle for Jitter
                                Universal Binaries on the way
iCE:  Sequencing,  Recording &
       Interface  Building  for                   |home    | chez nous|
       Max/MSP   Extremely cool                   |bei uns |  i nostri|
       http://www.dspaudio.com/                   http://www.castine.de

> At the time coll was first written, it was probably reasonable to 

> assume that a coll file would not contain more than 32,767 lines.

Wasn't that time not also a limit of 64k for the size of text objects? 

> The issue is indeed cosmetic. However, if you have an error in the 

> 999,999th line, the error message will be a little unhelpful.

actually there is also a non-cosmetic issue, with my million lines coll

the next message doesn't work. it will always put out the first element.

Peter Castine wrote:
> At the time coll was first written, it was probably reasonable to 
> assume that a coll file would not contain more than 32,767 lines.

Wasn't that time not also a limit of 64k for the size of text objects? 
That might explain that as well...

> The issue is indeed cosmetic. However, if you have an error in the 
> 999,999th line, the error message will be a little unhelpful.

actually there is also a non-cosmetic issue, with my million lines coll
the next message doesn't work. it will always put out the first element.
Its not urgent though...

On 24 Jul 2006, at 21:12, Stefan Tiedje wrote:

Oiks... Ever thought of using a database?

http://www.loadbang.net/space/Software/net.loadbang-SQL

http://www.loadbang.net/space/Software/net.loadbang-SQL/MySQL

nick rothwell -- composition, systems, performance -- 

	http://www.loadbang.net/space/Software/net.loadbang-SQL
	http://www.loadbang.net/space/Software/net.loadbang-SQL/MySQL

   nick rothwell -- composition, systems, performance -- http:// 
www.cassiel.com


> On 24 Jul 2006, at 21:12, Stefan Tiedje wrote:

> Oiks... Ever thought of using a database?

As I said, its not urgent, because doing what I did is asking for 

trouble. I was just wondering, and having that coll just did some tests...

I would store it into a buffer~/soundfile in this case, as there are 

only numbers stored and the access of a buffer with peek~ for sure is 

way more efficient. Just recalling the coll with a deferlowed counter 

would give me less than 10 hits per second, which is more than 100 ms 

And the soundfile is smaller than the coll file

I am even not sure if this should be fixed at all, as these experiments 

show, that coll is astonishingly stable. Its not worth to "fix" 

something which will never be a real world problem (Never change a 

The opposite is rather true, these little annoyance will force you to go 

for a more solid solution (if your coll would ever grow that big)...

Nick Rothwell wrote:
>
> On 24 Jul 2006, at 21:12, Stefan Tiedje wrote:
>
>> with my million lines coll
>
>
> Oiks... Ever thought of using a database?

As I said, its not urgent, because doing what I did is asking for 
trouble. I was just wondering, and having that coll just did some tests...

I would store it into a buffer~/soundfile in this case, as there are 
only numbers stored and the access of a buffer with peek~ for sure is 
way more efficient. Just recalling the coll with a deferlowed counter 
would give me less than 10 hits per second, which is more than 100 ms 
per query... (peek is immediate...).
And the soundfile is smaller than the coll file

I am even not sure if this should be fixed at all, as these experiments 
show, that coll is astonishingly stable. Its not worth to "fix" 
something which will never be a real world problem (Never change a 
winning team).

The opposite is rather true, these little annoyance will force you to go 
for a more solid solution (if your coll would ever grow that big)...

coll limits, maybe cosmetic...