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