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 http://www.xfade.com