Just Another Javascript based BIG [urn]

Julien Bayle's icon

Hi there,

I just wanted to post something I just retrieved in my old patchers.

It is a BIG [urn], based on javascript.

[urn] is still limited to 4096.

We all dealt with that but sometimes, when I need to extend the concept, I use this one.

You can get them there. There is a test in the leftmost part of the patch. Test it. It works even with 1000000 numbers in the list and theoretically even bigger numbers !

theBigUrn.zip
zip


Hope you'll enjoy this.


midinerd's icon

Hey Julien -

Cool implementation, thanks for sharing.

Question about javascript stuff - when you use javascript does it matter if you have it in a timing-dependent chain? Or another way of asking: Does anything rely directly on the promptness of the output of this huge urn? I love writing in javascript and am paranoid about timing, though I am also stubborn and still use it.

Does the question make sense? :) Do you query this js object and cache the result in parallel with other things going on, or is it fast enough you 'just' use it exactly like [urn] in a chain of process?

cheers

Julien Bayle's icon

it really depends on my needs. I already did project where I cached a bunch of things in kind of lookup tables.

In this case, it is very fast. It uses Fisher-Yates algorithm one time only, then you use the cache.

I cannot answer globally, it really depends on projects.

I'm more annoyed by objects that doesn't notify about 'job finished' than slowness of js.

It forces us to create mechanism of counting, delaying etc.

midinerd's icon

Yep, that's a good answer. Thanks for the insight

Emmanuel Jourdan's icon

I made one in Java years ago for that purpose :-) The algorithm is even simpler for the clear message, because you don't really need to reset the lookup table (it already contains all the number), so it only takes time to initialize the lookup, but after that it has a constant cost, and no CPU pic when you clear the table.

Iain Duncan's icon

If you are worried about timing, you could also try implementing this in Scheme using Scheme for Max, which allows running in the scheduler thread. The issue with JS is not so much that it is slow, but rather that it is running in the UI thread so the time of your code being run is dependent on what else you have going on in your patcher and can be very inconsistent.

An urn would be very easy to implement in Scheme!