line vs. line~ problem


    Mar 27 2008 | 10:48 pm
    Hi all -
    Hoping somebody can help me here (and I'm sorry if this has been covered - I tried searching several different combinations of words to no avail).
    I'm creating a very simple patch - a breakpoint function is attached to a line object, which is attached to a transposer, so that I can draw out and store various transposing shapes for the sounds I'm working with.
    Here's the problem...
    When I attach the line object to the function, it only follows through to the first breakpoint, at which point it stops (as expected). However, it runs through every float number, making the subsequent transposition very smooth.
    The problem with the line~ object is that it's movement through the function is very "jumpy" (is that a good word to use?). It does not cycle through ever float in between as does line, eliminating the glissando from the resulting transposition and giving it a rhythm I don't want. However, it does move all the way through the function!
    So, is there 1) a rig I can create that will essentially allow line to cycle through all of the various breakpoints to the very end OR 2) alter line~ so that it cycles through floats in the same way that line does (I don't know if the line~ problem has to do with sampling rate or the overall speed of the computer, or it's something in the object itself)?
    Any ideas? I hope this all made sense! I appreciate any feedback. :)
    Drew

    • Mar 27 2008 | 11:17 pm
      Hi,
      for a multi-segment line, you may try this - not the most precise nor
      elegant, but functionnal :
    • Mar 27 2008 | 11:22 pm
      I know recall that EJ might have done something similar (if not
      better) in his Ejies - surely it'll please you more that the previous
      hack.
    • Mar 27 2008 | 11:49 pm
      line~ seems to be very smooth to me. Could you post part of your patch so we can see/hear what's going on???
    • Mar 28 2008 | 12:30 am
      On 28 mars 08, at 00:22, Manuel Poletti wrote:
      > I know recall that EJ might have done something similar (if not
      > better) in his Ejies - surely it'll please you more that the
      > previous hack.
      that's right, there's ej.line (and many people have done the same
      kinda things).
      ej
    • Mar 28 2008 | 4:11 am
      What setting did you have for the 'time grain' argument in your
      [line~]? This sets the time resolution, so if yours was jumpy it may
      have been too large.
      On Mar 27, 2008, at 4:48 PM, dboles wrote:
      >
      > Hi all -
      > Hoping somebody can help me here (and I'm sorry if this has been
      > covered - I tried searching several different combinations of words
      > to no avail).
      > I'm creating a very simple patch - a breakpoint function is
      > attached to a line object, which is attached to a transposer, so
      > that I can draw out and store various transposing shapes for the
      > sounds I'm working with.
      > Here's the problem...
      > When I attach the line object to the function, it only follows
      > through to the first breakpoint, at which point it stops (as
      > expected). However, it runs through every float number, making the
      > subsequent transposition very smooth.
      > The problem with the line~ object is that it's movement through the
      > function is very "jumpy" (is that a good word to use?). It does
      > not cycle through ever float in between as does line, eliminating
      > the glissando from the resulting transposition and giving it a
      > rhythm I don't want. However, it does move all the way through the
      > function!
      >
      > So, is there 1) a rig I can create that will essentially allow line
      > to cycle through all of the various breakpoints to the very end OR
      > 2) alter line~ so that it cycles through floats in the same way
      > that line does (I don't know if the line~ problem has to do with
      > sampling rate or the overall speed of the computer, or it's
      > something in the object itself)?
      >
      > Any ideas? I hope this all made sense! I appreciate any feedback. :)
      ----
      Steven M. Miller
      Professor, Contemporary Music Program
      College of Santa Fe
      Home
      SFIFEM
      Atrium Sound Space
      OVOS
      CMP
    • Mar 28 2008 | 5:01 am
      Hello all -
      Thank you for all of the responses. I am including the pertinent portion of my patch so that you all can take a look.
      In reference to the last post re: 'time grain,' I am not sure where I would alter this. I have two inputs in the line~ object - is the right input? I thought it was a way to input a new time for the overall ramp? I could be wrong, though, as I am a lot.
      If this is something that can easily be fixed, I'd love to do it. Otherwise, I might look into the other objects mentioned earlier.
      Thanks again!
    • Mar 28 2008 | 5:14 am
      hey all -
      Out of curiosity, I wandered over to EJ's site, and the ej.line object seems to work perfectly for what I need. So, if you're not in the mood to investigate my previous patch, I'm fine with that.
      I would, however, be interested in learning how to set time grain on the line~ object. I can see how you would do it with line, but like I said, my line~ objects only have two inputs. Thoughts?
      Drew
    • Mar 28 2008 | 5:38 am
      On Mar 27, 2008, at 10:01 PM, dboles wrote:
      > Thank you for all of the responses. I am including the pertinent
      > portion of my patch so that you all can take a look.
      Your problem in in the use of number~ to convert from signal world to
      event world. In Max 4, number~ has a sample rate of 250 ms. This can
      be changed via its inspector. You could also use snapshot~ instead of
      number~.
      -C
      Chris Muir
      cbm@well.com