Drew Boles

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.

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. :)

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!

Any ideas?  I hope this all made sense!  I appreciate any feedback. :)

line-vs-line-problem

for a multi-segment line, you may try this - not the most precise nor 

for a multi-segment line, you may try this - not the most precise nor  
elegant, but functionnal :

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 

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.


line~ seems to be very smooth to me. Could you post part of your patch so we can see/hear what's going on???

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 

that's right, there's ej.line (and many people have done the same 

> 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).

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 

On Mar 27, 2008, at 4:48 PM, dboles wrote:

> Hoping somebody can help me here (and I'm sorry if this has been 

> covered - I tried searching several different combinations of words 

> 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 

> 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 

> 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 

> 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 

> Any ideas? I hope this all made sense! I appreciate any feedback. :)

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 


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.

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!

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?

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?

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 

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~.

Chris Muir
cbm@well.com	
http://www.xfade.com

line vs. line~ problem