need a flush update (some bug reports)


    Nov 29 2006 | 9:43 am
    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:
    -- Stefan Tiedje------------x------- --_____-----------|-------------- --(_|_ ----|-----|-----()------- -- _|_)----|-----()-------------- ----------()--------www.ccmix.com

    • Nov 29 2006 | 2:42 pm
      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.)
      -------------- 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
    • Nov 29 2006 | 2:45 pm
    • Nov 30 2006 | 7:07 am
      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
    • Nov 30 2006 | 11:10 am
      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.
      -------------- 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