Stefan Tiedje

flush has a completely useless restriction:

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 

Suggestion: an additional parameter would set a mode without that 

restriction. (For the sake of the eventual, though very unlikely, 

I'd rather like to have flush fixed, than adding another abhaXion to my 

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 

By the way, k-slider if in a range exceeding 127 will not switch off 

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 

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

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....

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... ;-)

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


need-a-flush-update-some-bug-reports

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 

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 

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 

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

> flush has a completely useless restriction:

> 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 

> Suggestion: an additional parameter would set a mode without that 

> restriction. (For the sake of the eventual, though very unlikely, 

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

Interface Building for |home | chez nous|

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

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.

> 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.)

--------------    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

> 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 

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 

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...

On 30-Nov-2006, at 8:07, Stefan Tiedje 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];

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 

> 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, 

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 

> 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,

	const int kFlushArraySize = /*currently 128 */

	// 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.

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.

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.

need a flush update (some bug reports)