More elegant solution than short delay? Using function as envelope.

    Dec 10 2013 | 2:37 am
    I've created an elaborate Rube Goldbergc machine to make [Function] work as an envelope for [Line~]. The reason for this was to get [Function]'s output in a list in a form that [Line~] can read and also to [Scale] the x axis points (time) so that the total domain of the function object comes out as the total time of the envelope.
    First, is there a better way to use [Function] with [Line~]?
    Second, as I indicated in the patch, this only works if a bang is sent with a 5 millisecond delay after a "dump" message has been sent to [Function]. Is there a more elegant way to accomplish this?
    Thanks! ~Daniel

    • Dec 10 2013 | 3:14 am
      not sure what you are doing there with that [thresh].
      function can output a list in [line] format, and that suggest to just change this data to [line~] format.
      and when you want to store this list, [zl reg] is your friend.
      for example this is my envelope abstraction. among other things, i also use it to place it inside a poly~ and connect a function object to it. first input triggers, second input expects list in line format and "set"s it.
    • Dec 10 2013 | 3:28 am
      I'm not sure how to make that work. Here's what I get with the second-from-left outlet with my [Function] set to "list output." As you can see, the [Function] doesn't seem to send velocity/time pairs. I couldn't get this to work. Am I missing something? This is why I ended up building something to use the second-to-right inlet with that [thresh] hack.
      I'm not using [zl reg] at the moment because zl objects have been buggy on my computer lately. (See my other forum post about Max File Path, the comment further down the page.)
      Thanks for your help, Roman. I don't understand your envelope abstraction though. Do the inlets connect to the two middle outlets of [Function]?
    • Dec 10 2013 | 3:58 am
      after editing my above post 3 times it hopefully makes sense now. the usual line and line~ confusion just got me there, too.
      well, those are value/time pairs when you set the function object to the range you want. like say "2000 milliseconds" and 0.-1. for "gain". try functions seconds outlet with the non MSP line directly to compare how it works there. with line~ you only have to change the format a bit (seperating the starting value from the list)
      here is 2 files, pls remove the .mxb if you are on mac.
    • Dec 10 2013 | 4:05 am
      Function can already send a list suitable for using line~ (even says it in the help file), so no elaborate schemes needed.
      Not sure what's going on with the pic posted but can you go into the function object's inspector and see what the output mode is set to?
      The Normal and List setting can give different results depending on what you're trying to do. I believe "Normal" is the default for use with line~.
    • Dec 10 2013 | 9:36 am
      I'm sorry. Maybe I'm just particularly thick this evening, but I'm still a bit lost. It seems to me that [Function] only sends output suitable for [Line~] in a step-through mode with a "next" command triggering each new x-y coordinate. This is the only way it’s demonstrated in the help file. What I'm looking for is a single list suitable for a [Line~] envelope (something like [0, 1 5000 0.3 500 0.8 500 0 1000]). Function doesn't seem to output anything like that in any of its modes.
      To help illustrate the issue I’m having I created an annotated example bellow. Please take a look and tell me what I’m missing. I’ve been using Max for years, but I’ve never understood how to use [Function] in this way!
    • Dec 10 2013 | 3:37 pm
      Usage of function for what you're describing: bang in left inlet, connect second (!) outlet to line~.
      I advocate using list mode as well because the timing will be more consistent since the data will be sent as one message rather than two.
      Re: the "next" message: are you adding points by clicking, or by command-clicking? You want the first one. The second one adds sustain points which might account for why things weren't continuing.
    • Dec 11 2013 | 1:32 am
      "0, 1 5000 0.3 500 0.8 500 0 1000" ... is exactly what the second outlet should give you.
      and from what i know that should be default, no need to choose an output mode. (unless they changed that in max 6.x?)
      i can only look at your patch with the runtime right now, but i have to admit that in your patch i can reproduce that it does work like it should. can it be that you are using a breakpoint for all of these points? i bet if you start again using a fresh created function object, it will output properly in line~ format without cutting everything off after the first pair.