Cycling 74 » Topic: need a flush update (some bug reports)

need a flush update (some bug reports)

Stefan Tiedje — Wed, 29 Nov 2006 09:43:38 +0000

flush has a completely useless restriction:
Its restricted to notes from 0 to 127!

Its that useless, that I would call it a bug.

I represent microintervals with a cent representation. The middle C is
6000, the D is 6200. A quartertone sharp of C is 6050…

I need to have a flush which does accept all integers (also negative
numbers). I understand that the amount of polyphony flush can deal with
might be restricted.

Suggestion: an additional parameter would set a mode without that
restriction. (For the sake of the eventual, though very unlikely,
possibility of breaking old patches.)

I’d rather like to have flush fixed, than adding another abhaXion to my
collection…

I tried borax as workaround, it reports other notes as 0 to 127, but
doesn’t flash them! this certainly needs to be fixed as well…
Borax also doesn’t accept multiple triggers for the same note (as
documented in the manual)…

By the way, k-slider if in a range exceeding 127 will not switch off
notes in poly mode….

And to fullfill the bugreport guide lines:

I expect flush to work with all integers,
I expect borax to flush all held notes also those exceeding the 0-127 range.
I expect k-slider to switch off notes exceeding the 0-127 range in
polymode. (this is the least urgent of all, but seems just logical to be
fixed… ;-)

All three to explore:

#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P newex 193 213 69 196617 prepend set;
#P button 176 213 15 0;
#P button 187 122 15 0;
#P message 232 237 63 196617 20 , 20 , 135;
#P number 193 237 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P message 193 263 50 196617 $1 0;
#P message 245 141 63 196617 20 , 20 , 135;
#P number 206 141 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P message 206 164 50 196617 $1 64;
#P number 225 109 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 343 295 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 500 108 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P user kslider 63 66 35 1 120 48 19 7 1 128 128 128 128 128 128 255 255
255 0 0 0 0 0 0;
#P number 63 108 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 63 242 40 196617 print f;
#P newex 63 220 32 196617 pack;
#P user kslider 313 66 35 1 120 48 19 7 1 128 128 128 128 128 128 255
255 255 0 0 0 0 0 0;
#P button 433 168 15 0;
#P newex 357 256 43 196617 print b;
#P newex 357 234 32 196617 pack;
#P newex 313 205 130 196617 borax;
#P button 30 125 15 0;
#P newex 63 196 32 196617 flush;
#P number 313 108 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P comment 381 295 84 196617 number of notes;
#P connect 4 3 5 0;
#P connect 4 4 5 1;
#P connect 7 0 4 2;
#P connect 4 2 14 0;
#P fasten 1 0 24 0 318 200 198 200;
#P connect 1 0 4 0;
#P fasten 19 0 4 0 198 289 294 289 305 202 318 202;
#P fasten 16 0 4 0 211 184 318 184;
#P fasten 17 0 24 0 211 161 198 161;
#P connect 17 0 16 0;
#P connect 11 0 2 0;
#P connect 24 0 20 0;
#P fasten 18 0 16 0 250 161 211 161;
#P fasten 21 0 19 0 237 257 198 257;
#P connect 20 0 19 0;
#P connect 22 0 17 0;
#P connect 23 0 20 0;
#P connect 12 1 15 0;
#P connect 8 1 13 0;
#P connect 12 0 11 0;
#P connect 5 0 6 0;
#P connect 9 0 10 0;
#P connect 2 1 9 1;
#P connect 2 0 9 0;
#P connect 8 0 1 0;
#P connect 3 0 2 0;
#P window clipboard copycount 25;

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

Re: need a flush update (some bug reports)

Peter Castine — Wed, 29 Nov 2006 14:42:03 +0000

Flush, like a lot of classic Max objects, is highly MIDI-centric.

The notion of having a parameter to override the default range is a
reasonable one, however I’d suggest following the lead of objects
like table, Histo, and random: an integer sets the range upper bound.
For complete consistency it would be the exclusive upper bound (which
confuses a lot of people but it’s consistent… I hope the
consistency people are reading this!-)

Flush almost certainly needs to allocate a buffer to track note on
events (or whatever you’e using it for) and that buffer wants to be
allocated at instantiation time.

In the above scenario you could handily deal with negative values
with the aid of a little wrapper abstraction.

An ‘unlimited’ range is impossible since integers on a computer are
limited anyway, in Max to the range [-2,147,483,648 ..
2,147,483,647]. Sure, you might want to use that range but I’m pretty
sure that the current implementation of flush would require a 16
terabyte buffer to handle it.

Who has 16TB memory installed?

On 29-Nov-2006, at 10:43, Stefan Tiedje wrote:

> flush has a completely useless restriction:
> Its restricted to notes from 0 to 127!
>
> Its that useless, that I would call it a bug.
>
> I represent microintervals with a cent representation. The middle C
> is 6000, the D is 6200. A quartertone sharp of C is 6050…
>
> I need to have a flush which does accept all integers (also
> negative numbers). I understand that the amount of polyphony flush
> can deal with might be restricted.
>
> Suggestion: an additional parameter would set a mode without that
> restriction. (For the sake of the eventual, though very unlikely,
> possibility of breaking old patches.)

Re: need a flush update (some bug reports)

Jean-Francois Charles — Wed, 29 Nov 2006 14:45:04 +0000

Re: need a flush update (some bug reports)

Stefan Tiedje — Thu, 30 Nov 2006 07:07:55 +0000

Peter Castine wrote:
> An ‘unlimited’ range is impossible since integers on a computer are
> limited anyway, in Max to the range [-2,147,483,648 .. 2,147,483,647].
> Sure, you might want to use that range but I’m pretty sure that the
> current implementation of flush would require a 16 terabyte buffer to
> handle it.

That would assume a pretty ineffective algorithm, I am sure there are
other more memory effective ones. As I said I would not ask for
unlimited polyphony, I’d be happy with 128 or 256 maximum voices and an
undocumented unforeseable behaviour if exceeding it (like voice stealing
and switching of old notes without being asked… ;)
The old flush might have been optimized for speed which was an issue in
68000 days for this kind of stuff…

Stefan

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

Re: need a flush update (some bug reports)

Peter Castine — Thu, 30 Nov 2006 11:10:25 +0000

On 30-Nov-2006, at 8:07, Stefan Tiedje wrote:

> Peter Castine wrote:
>> An ‘unlimited’ range is impossible since integers on a computer
>> are limited anyway, in Max to the range [-2,147,483,648 ..
>> 2,147,483,647]. Sure, you might want to use that range but I’m
>> pretty sure that the current implementation of flush would
>> require a 16 terabyte buffer to handle it.
>
> That would assume a pretty ineffective algorithm,

Not so much ‘ineffective’ as simple and fast.

const int kFlushArraySize = /*currently 128 */

int stateArray[kMaxFlushArraySize];

.
.
.

// Set flag that note is ‘on’
stateArray[curNote] = 1;

.
.
.

// Set flag that note is ‘off’
stateArray[curNote] = 0;

.
.
.

// Check state of note
if (stateArray[curNote])
// do whatever…

This will generate about the fastest machine code possible. Working
with an array of bytes would reduce memory requirements by 75% but
would require additional machine code for testing state. Memory
requirements could be reduced by an additional 7/8 by using a bit
vector, but there is even more code involved. Disassembling the old
Mac Toolbox traps BitTest(), BitSet(), and BitClear(), which do
exactly that, is an educational experience I would highly recommend.

None of this is undoable, but I can well imagine that a very simple &
fast algorithm held a lot of attraction when building the object. And
requiring 0.5kB for managing state of MIDI notes doesn’t seem
unreasonable.

> I am sure there are other more memory effective ones.

There are programming techniques for dealing with very large ‘sparse’
arrays, but they are quite intricate. I did this for ice.lattice and,
trust me, it is pretty knarly.

– Peter

DISCLAIMER: I do not claim that the pseudo-code above is how flush is
actually implemented. It’s just one, fairly typical, approach to the
task.