cebec

This should be an easy one, and I've tried numerous things, but I just can't seem to get it. I'd like to have various waveforms at my disposal to send via ctlout (to an MIDI/CV converter): sine, tri, rectangle, saw, etc., and a bonus would be to be able to draw my own waveforms. 

In addition, I've been trying to figure out how to use line with the function editor and send arbitrarily complex envelopes out of ctlout, as well. 

My problem is: I can't figure out how to get basic waveshapes in Max without resorting to MSP, and when I do, there's the problem of 'translating' them to MIDI. I gather I need to scale any signal I intend to send out of ctlout to 0-127.

Any help or tips would be much appreciated,

This should be an easy one, and I've tried numerous things, but I just can't seem to get it. I'd like to have various waveforms at my disposal to send via ctlout (to an MIDI/CV converter): sine, tri, rectangle, saw, etc., and a bonus would be to be able to draw my own waveforms.  
In addition, I've been trying to figure out how to use line with the function editor and send arbitrarily complex envelopes out of ctlout, as well.  
My problem is: I can't figure out how to get basic waveshapes in Max without resorting to MSP, and when I do, there's the problem of 'translating' them to MIDI. I gather I need to scale any signal I intend to send out of ctlout to 0-127.
Any help or tips would be much appreciated,
Thanks!


midi-lfos-and-env

You can use line in conjunction with a table to draw your own waveforms. Here is an example:

Also, here is a patch someone posted on the forums a long time ago. I found this when trying to approach a similar idea. I don't know who made it, but its invaluable! It generates a number of different curves in tables, which you can cycle up and down with line to make waveforms.

Also note that this number box in the upper right will adjust the curves. You can then just save the data into a text file for quick loading.

Also, here is a patch someone posted on the forums a long time ago. I found this when trying to approach a similar idea. I don't know who made it, but its invaluable! It generates a number of different curves in tables, which you can cycle up and down with line to make waveforms. 

Also note that this number box in the upper right will adjust the curves. You can then just save the data into a text file for quick loading. 

If anyone has any further suggestions re: the Function editor with line and creating basic waveforms with pre-existing objects, please chime in...

Is there a way to change the line's ramp time dynamically while it's in such a loop as that in the first patch?

> If anyone has any further suggestions re: the Function editor with 

> line and creating basic waveforms with pre-existing objects, please 

Check out lp.scampi.help and the patcher newStuff.

Peter Castine +--> Litter Power & Litter Bundle for Jitter

Interface Building for |home | chez nous|

Max/MSP Extremely cool |bei uns | i nostri|

On 18-Jul-2006, at 22:51, matt wrote:
> If anyone has any further suggestions re: the Function editor with  
> line and creating basic waveforms with pre-existing objects, please  
> chime in...

--------------    http://www.bek.no/~pcastine/Litter/    -------------
Peter Castine             +--> Litter Power & Litter Bundle for Jitter
                                Universal Binaries on the way
iCE:  Sequencing,  Recording &
       Interface  Building  for                   |home    | chez nous|
       Max/MSP   Extremely cool                   |bei uns |  i nostri|
       http://www.dspaudio.com/                   http://www.castine.de

Yes! And I own a license for Litter Pro, too... Sometimes the best solutions are right under our noses.

lp.scampi does not handle negative floats/ints, it seems, right? i still cannot, for e.g., use a low frequency cycle~ to control a VCO via MIDI/CV...

> lp.scampi does not handle negative floats/ints, it seems, right? i 

> still cannot, for e.g., use a low frequency cycle~ to control a VCO 

Scampi will handle any numbers you ask it to.

The default input range is 0..1, but you can write explicit arguments 

in the object box for a different range, or send messages to the 2nd 

The default output range is 0..127, but you can change that, too.

You can change everything else in scampi's behavior (symmetry, curve/ 

On 19-Jul-2006, at 1:56, matt wrote:
> lp.scampi does not handle negative floats/ints, it seems, right? i  
> still cannot, for e.g., use a low frequency cycle~ to control a VCO  
> via MIDI/CV...

The default input range is 0..1, but you can write explicit arguments  
in the object box for a different range, or send messages to the 2nd  
& 3rd inlets.

You can change everything else in scampi's behavior (symmetry, curve/ 
kink, handling of out-of-bounds input).

I've always been a big fan of Panaiotis' autocount

object for creating non-audio rate LFO's, because it's

an easy one-stop object for creating all the usual

And another worthy curve builder is Tristan Jehan's

I'm not sure if either ever got ported to Windows, but

you should be able find them via maxobjects.com,

> If anyone has any further suggestions re: the

> Function editor with line and creating basic

> waveforms with pre-existing objects, please chime

I've always been a big fan of Panaiotis' autocount
object for creating non-audio rate LFO's, because it's
an easy  one-stop object for creating all the usual
LFO wave shapes but very flexible too.
 And another worthy curve builder is Tristan Jehan's
mapper object.
I'm not sure if either ever got ported to Windows, but
you should be able find them via maxobjects.com,
cheers
Roger

>
> These are fantastic aids. Many thanks!
>
> If anyone has any further suggestions re: the
> Function editor with line and creating basic
> waveforms with pre-existing objects, please chime
> in...
>
>

Thanks, everyone... No, those two objects haven't been ported... yet. That's ok, I think I can still make-do with what I have right now. I'm just surprised there isn't some REALLY easy way to do this. I thought a cycle~ to snapshot~ or number~ to lp.scampi or scale would've done the trick but it doesn't...

Thanks, everyone... No, those two objects haven't been ported... yet. That's ok, I think I can still make-do with what I have right now. I'm just surprised there isn't some REALLY easy way to do this.   I thought a cycle~ to snapshot~ or number~ to lp.scampi or scale would've done the trick but it doesn't...


this may have been suggested already... but how about a for-loop, and a 

formula. or maybe a for loop and a lookup table or lots of lookup 

tables... i mean you could just build stuff that works the same way as 

your favorite audio tools, but at lower and slower resolution...

if you know math and/or digital signal theory it should take you around 

38 minutes to do what you want using javascript or java or rtcmix~ or 

47 minutes using traditional max objects...

output of LFO curves of your design at event rate...

> Thanks, everyone... No, those two objects haven't been ported... 

> yet. That's ok, I think I can still make-do with what I have right 

> now. I'm just surprised there isn't some REALLY easy way to do 

> this. I thought a cycle~ to snapshot~ or number~ to lp.scampi or 

> scale would've done the trick but it doesn't...

this may have been suggested already... but how about a for-loop, and a 
formula.  or maybe a for loop and a lookup table or lots of lookup 
tables...  i mean you could just build stuff that works the same way as 
your favorite audio tools, but at lower and slower resolution...

if you know math and/or digital signal theory it should take you around 
38 minutes to do what you want using javascript or java or rtcmix~ or 
47 minutes using traditional max objects...

for-loop or [counter]
formula or table
additional formula or table
...
output of LFO curves of your design at event rate...

> Thanks, everyone... No, those two objects haven't been ported... 
> yet. That's ok, I think I can still make-do with what I have right 
> now. I'm just surprised there isn't some REALLY easy way to do 
> this.   I thought a cycle~ to snapshot~ or number~ to lp.scampi or 
> scale would've done the trick but it doesn't...


this is about as far as I've gotten. try a tri~, too... i haven't gotten it quite right...

this is about as far as I've gotten.  try a tri~, too... i haven't gotten it quite right...

> this is about as far as I've gotten. try a tri~, too... i haven't 

The map symbol puts scampi in map mode. In map mode the first two 

numeric arguments set the input range. The default output range, 

0-127, is fine so no need for any more arguments. As long as the 

input values are in range, there's no need for the reflect/wrap/etc. 

Somewhere along the line some of your patcher was HTML-ized, causing 

some problems with "New from Clipboard." This should iron out those 

On 19-Jul-2006, at 22:23, matt wrote:
> this is about as far as I've gotten.  try a tri~, too... i haven't  
> gotten it quite right...

The map symbol puts scampi in map mode. In map mode the first two  
numeric arguments set the input range. The default output range,  
0-127, is fine so no need for any more arguments. As long as the  
input values are in range, there's no need for the reflect/wrap/etc.  
popup menu.

Somewhere along the line some of your patcher was HTML-ized, causing  
some problems with "New from Clipboard." This should iron out those  
issues:

fantastic. that solidifies it for me, thanks.

> Any help or tips would be much appreciated, Thanks!

The right inlets are for frequency in Herz, if you want to have the 

timing more exact, you need to syncronize them instead of self triggering.

This should give you enough ideas to go on...

matt wrote:
> Any help or tips would be much appreciated, Thanks! 

The right inlets are for frequency in Herz, if you want to have the 
timing more exact, you need to syncronize them instead of self triggering.
This should give you enough ideas to go on...

-- 
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com


Thank you VERY much, Stefan. I found lines, too.

> The default output range is 0..127, but you can change that, too.

unfortunately its still 0...128 (just checked again (with the hope that 

it had changed in the mean time)), though I believe it would not break a 

single patch if it would be changed to 0...127, as its pretty unlikely 

that the default is ever used in a real patch...

Peter Castine wrote:
> The default output range is 0..127, but you can change that, too.

unfortunately its still 0...128 (just checked again (with the hope that 
it had changed in the mean time)), though I believe it would not break a 
single patch if it would be changed to 0...127, as  its pretty unlikely 
that the default is ever used in a real patch...

On 21-Jul-2006, at 11:40, Stefan Tiedje wrote:

> unfortunately its still 0...128 (just checked again (with the hope 

> that it had changed in the mean time)), though I believe it would 

> not break a single patch if it would be changed to 0...127, as its 

> pretty unlikely that the default is ever used in a real patch...

You're quite right that lp.scampi's default output range is 0 to 128. 

And, as Klaus Wowereit says, it's a good thing too. Let me explain.

The scampi/scampf pair were designed for mapping output from Litter 

unit-range RNGs to MIDI and back. A careful look at the unit-range 

random number generators reveals that they generate values in the 

multiply the input by 128 and truncate, giving integers in the range 

Note also that if the input values have a flat distribution, so do 

the output values. This would not be the case if scampi used the more 

naive approach of multiplying by 127. You can test this yourself by 

editing the lp.scampi object in lp.shhh.help to 'lp.scampi map 0 1 0 

127'. Then bang Uzi a few times. How many 127s show up in the histogram?

As for breaking "real-world" patches: scampi was, as I said, 

originally designed for scaling output of RNGs to the standard table 

range, as exemplified in a dozen lp.*.help patches. Furthermore I've 

used scampi with its default settings in many real-life projects.

Like right-to-left order, this is an example of where the most 

On 21-Jul-2006, at 11:40, Stefan Tiedje wrote:
> unfortunately its still 0...128 (just checked again (with the hope  
> that it had changed in the mean time)), though I believe it would  
> not break a single patch if it would be changed to 0...127, as  its  
> pretty unlikely that the default is ever used in a real patch...

You're quite right that lp.scampi's default output range is 0 to 128.  
And, as Klaus Wowereit says, it's a good thing too. Let me explain.

The scampi/scampf pair were designed for mapping output from Litter  
unit-range RNGs to MIDI and back. A careful look at the unit-range  
random number generators reveals that they generate values in the  
half-open range 0
multiply the input by 128 and truncate, giving integers in the range  
0 

Note also that if the input values have a flat distribution, so do  
the output values. This would not be the case if scampi used the more  
naive approach of multiplying by 127. You can test this yourself by  
editing the lp.scampi object in lp.shhh.help to 'lp.scampi map 0 1 0  
127'. Then bang Uzi a few times. How many 127s show up in the histogram?

As for breaking "real-world" patches: scampi was, as I said,  
originally designed for scaling output of RNGs to the standard table  
range, as exemplified in a dozen lp.*.help patches. Furthermore I've  
used scampi with its default settings in many real-life projects.

Like right-to-left order, this is an example of where the most  
obvious approach is not the best.

> The scampi/scampf pair were designed for mapping output from Litter 

> unit-range RNGs to MIDI and back. A careful look at the unit-range 

> random number generators reveals that they generate values in the 

> multiply the input by 128 and truncate, giving integers in the range 0 

Thanks for that clear and understandable explanation. I promise I'll 

never rumble about that ever again. Just to avoid wrong thinking for 

other users, just put that explanation patch into your help file...

In general a bit more basic explanation about all your wonderful 

distributions would be helpful aswell. I know its possible to search for 

such in the web, but if you are patching, a little explanation within 

the helpfile is just more convenient than searching the web for "what 

I am sure you could write a book about all these distributions and their 

Peter Castine wrote:
> The scampi/scampf pair were designed for mapping output from Litter  
> unit-range RNGs to MIDI and back. A careful look at the unit-range  
> random number generators reveals that they generate values in the  
> half-open range 0
> multiply the input by 128 and truncate, giving integers in the range  0 
>

Thanks for that clear and understandable explanation. I promise I'll 
never rumble about that ever again. Just to avoid wrong thinking for 
other users, just put that explanation patch into your help file...

In general a bit more basic explanation about all your wonderful 
distributions would be helpful aswell. I know its possible to search for 
such in the web, but if you are patching, a little explanation within 
the helpfile is just more convenient than searching the web for "what 
the hell does mu or sigma mean..."

I am sure you could write a book about all these distributions and their 
occurances in the real world...

-- 
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com

On 27-Jul-2006, at 7:50, Stefan Tiedje wrote:

> In general a bit more basic explanation about all your wonderful 

> distributions would be helpful aswell. I know its possible to 

> search for such in the web, but if you are patching, a little 

> explanation within the helpfile is just more convenient than 

> searching the web for "what the hell does mu or sigma mean..."

Up to the current release of Litter, I followed the documentation 

paradigm given by Opcode and Cycling: quick overview in the .help 

My experience in coaching and user support is that real people very 

rarely crack open the book, even when the book is a .PDF file. Also, 

some of the reasons for keeping .help files small that were valid in 

the late 80s no longer hold. So I am in the process of moving all 

The process won't be completed in the next release, it's really a 

massive task. But you should find a lot more information immediately 

available. I'll try to include a note about mu and sigma.

> I am sure you could write a book about all these distributions and 

Yeah, that's the problem. Who wants to read a book?

On 27-Jul-2006, at 7:50, Stefan Tiedje wrote:
> In general a bit more basic explanation about all your wonderful  
> distributions would be helpful aswell. I know its possible to  
> search for such in the web, but if you are patching, a little  
> explanation within the helpfile is just more convenient than  
> searching the web for "what the hell does mu or sigma mean..."

Up to the current release of Litter, I followed the documentation  
paradigm given by Opcode and Cycling: quick overview in the .help  
file, details in the Reference Manual.

My experience in coaching and user support is that real people very  
rarely crack open the book, even when the book is a .PDF file. Also,  
some of the reasons for keeping .help files small that were valid in  
the late 80s no longer hold. So I am in the process of moving all  
documentation into the .help files.

The process won't be completed in the next release, it's really a  
massive task. But you should find a lot more information immediately  
available. I'll try to include a note about mu and sigma.

> I am sure you could write a book about all these distributions and  
> their occurances in the real world...

> The process won't be completed in the next release, it's really a 

> massive task. But you should find a lot more information immediately 

> available. I'll try to include a note about mu and sigma.

Actually if you know of a possibility to use launchbrowser not only for 

calling the manual, but also to jump to a specific chapter within the 

PDF, let me know. (Preferably for Preview, as Acrobat Reader is way too 

That might even do it as link within the help file...

Peter Castine wrote:
> The process won't be completed in the next release, it's really a  
> massive task. But you should find a lot more information immediately  
> available. I'll try to include a note about mu and sigma.

Actually if you know of a possibility to use launchbrowser not only for 
calling the manual, but also to jump to a specific chapter within the 
PDF, let me know. (Preferably for Preview, as Acrobat Reader is way too 
heavy for my taste.)
That might even do it as link within the help file...

Oh yeah, of course! Sorry! Here's a quote from one of her emails:

At 4:39 PM -0700 10/5/06, Lauren Pratt wrote:

>My CalArts email address has changed: it is now lpratt@calarts.edu. Please

>Lauren Pratt, Associate Producer for Music

>REDCAT (Roy and Edna Disney/CalArts Theater)

>California Institute of the Arts, School of Music

I'll work on "stoned and in a dormroom". Maybe that's the answer to 

(I forward my land line to my mobile phone when I'm travelling)

shipping address (for packages larger than a 9" x 12" envelope):

Pamela Z 2440 Sixteenth Street PMB #171, San Francisco, CA 94103, USA

Pamela Z's CD "A Delay is Better" on the Starkland label is now 

......................................................................................................

Oh yeah, of course!  Sorry!  Here's a quote from one of her emails:

At 4:39 PM -0700 10/5/06, Lauren Pratt wrote:
>My CalArts email address has changed: it is now lpratt@calarts.edu. Please
>note this in your address book.
>
>Lauren Pratt, Associate Producer for Music
>REDCAT (Roy and Edna Disney/CalArts Theater)
>California Institute of the Arts, School of Music
>24700 McBean Parkway
>Valencia, CA 91355-2397
>661-799-0226, 1-888-277-1190 toll-free
>Fax: 661-670-0151
>lpratt@calarts.edu
>
>http://www.redcat.org

I'll work on "stoned and in a dormroom".  Maybe that's the answer to 
all my problems of late...

Telephone: 415.861.EARS (415.861.3277)
Mobile: 415.5PAMELA (415.572.6352)
FAX: 415.861.FAKS (415.861.3257)
(I forward my land line to my mobile phone when I'm travelling)

pamelaz@pamelaz.com
http://www.pamelaz.com

Snail Mail:
Pamela Z Productions
540 Alabama Street Studio 213
San Francisco, CA 94110, USA

shipping address (for packages larger than a 9" x 12" envelope):
Pamela Z  2440 Sixteenth Street  PMB #171, San Francisco, CA 94103, USA

Pamela Z's CD "A Delay is Better" on the Starkland label is now 
available at http://www.amazon.com, http://www.starkland.com, and in 
stores near you.
......................................................................................................


MIDI LFOs and Env