translate msp [line~] into gen~ [counter]

    Jul 07 2013 | 11:03 am
    I am trying to get the same functionality from [line~] inside gen~. I would like to send [counter] instructions as follows:
    go to 1. in X ms;
    go to 0. immediately;
    stay at 0. for Y ms.
    X and Y will be variable.
    The main challenge is working out how to tell [counter] to wait. I'm fairly sure there isn't a direct equivalent to [line~] in the gen world. The MaxMSP version is below fwiw:
    Thanks for looking Brendan

    • Jul 07 2013 | 12:57 pm
      to tell a gen~ operator output to "wait", the basic trick is to use a [?] or [sah] operator. What do you mean by [counter] btw ? the actual Max object ? because there is none in your patch, and there is no [counter] operator in gen afaik... there's [accum] though I'll try and see what i can do...
    • Jul 07 2013 | 1:22 pm
      There most certainly is a counter operator in gen~, although it was not among the early basic list of operators. It counts samples, of course. About the only differences you'll notice is that you'll have to add the "reset on next" count stuff yourself, and the additions of modes of counting [up/down/updown] are left as an "exercise to the genner."
      In connection to a little piece of gen~ mischief I was putting together, I realized that it would be very useful to have something in the toolbox that would smooth an input over N samples - which I think is basically what you have in mind. Implementing it proved a more challenging task than I initially assumed. While I languished in the Slough of Despond, I mentioned my suffering to Emmanuel Jourdan [who is owed a drink by quite a number of you by now, and many more by me personally], who kindly suggested that I consider something like this (which you should paste into an empty gen~ object):
      Perhaps it may prove to be as instructive to you as it was to me.
      Rock on, B.
    • Jul 07 2013 | 1:26 pm
      Hi vichug [counter] in gen~ works like [accum] and [+=]. Did you find it?
      Recently, I have seen related solutions using [accum] and I am now trying (for reasons of skills development and patch v. CPU optimization) to roll my own. I could be wrong but I believe that using [accum] in a polyphonic context can make excessive demands on memory and/or CPU.
      This solution from Peter McCullough and leafcutter. TBH I can't recall why this one didn't turn out to be perfect, maybe it's just the polyphonic load on my machine?
    • Jul 07 2013 | 1:42 pm
      I will have a hacky Sunday, thank you gents
    • Jul 07 2013 | 1:46 pm
      Hah... by the time i refreshed the page, i just finished finding what seems like a solution... probably useless by now, but here it is anyway :
      even more useless, as i don't use the most recent version of Max (6.O.8) that's certainley why i see no [counter] :) and i indeed do use accum, but to achieve this you'll have to somehow count somehting ? so using accum or count is maybe unavoidable ? not sure but....
    • Jul 07 2013 | 2:40 pm
      @noob_meister: latch is a easier solution to do sample & hold (new in Max 6.1.x).
    • Jul 07 2013 | 2:52 pm
      Ah, no [counter] in gen~ for you at the moment. I think the reason I want to avoid using [accum] or [+=] with no upper limit is to test a solution where the [accum], [counter] or whatever is constrained between 0. and 1. to see if I get a noticeable improvement in CPU usage. Apologies for the "duplication of effort"; your solution is a useful addition/alternative to leafcutter's.
      yes, I think I see where the clues left by yourself and Gregory are leading. Using the objects' reference as, erm, reference is the difference that latch truly samples or holds, where sah is either on or off? I could use latch to do the "waiting" part of my MSP solution?
      Thank you again Brendan
    • Jul 07 2013 | 8:27 pm
      You betcha, Brendan. Good call!
    • Jul 09 2013 | 3:59 pm
      Almost there gents; driving [latch] with a DIY rectangle wave for "off" and "on".
      Some confusion remains in syncing the control signal ("wait") to the central phasor.
      Maybe I need to spend time with that good old Zen and the Silent Patch tutorial ;¬)
    • Jul 13 2013 | 12:36 pm
      Even closer:
    • Aug 23 2014 | 11:59 am about this one? its just like line~ but its a bit loong
    • Aug 24 2014 | 12:41 am
      hope i'm understanding what kind of line~ usage...(i'm assuming just a destination value, and a linear ramp of variable time in ms)... this could work, too:
      edit: oh wait, you specifically want to use 'counter'... you could do that here, too, just replace "+=" with "counter" and work the mstosamps output into counter's max. (sorry i didn't find this before(fun thread!)... it reminds me, @vichug had an fdn thingie in gen~ i said i'd look into... shetballz, i forgot!)
    • Aug 24 2014 | 6:39 am
      heeey yours is much more elegant i feel like an elephant... --but when you turn on cpu-metering,its a bit more heavy than mine.. one way to improve this was to add a "fixdenorm" after the "history".. (i need this for some simple parameter smoothing,but inside a poly~ with 64 voices,thats why efficiency is BIG)
    • Aug 24 2014 | 8:49 am
      i feel like an elephant…
      ha, no! your math was another elegant way in my opinion(the efficiency gain proves it).
      ah yes, efficiency is something i could improve upon...
      thinkin of other improvements, since ramptime is held until the next destination value, it doesn't need to be sample accurate, and the 'mstosamps' conversion could happen outside of gen~ in scheduler realm, plus, it can be turned into a reciprocal so that the divide op within the gen~ patcher can be a multiply instead and the 'mstosamps' within gen~ can be removed entirely. additionally, instead of 'change'->'!= 0', i should've just used 'delta' :p and finally, i tried out 'interp' instead of 'mix', not entirely sure, but it seems to use less cpu?
    • Aug 24 2014 | 10:43 am
      Good morning people
      Here's a small patch with a solution offered by either leafcutter john or Andrzej Kopec (I think the former):
      My own compromise algo is there to. [latch] is the key object, from this thread. I was originally looking for a mutable 0. - 1. phasor, whose ramptime doesn't vary during muting.