Subject: MAX Digest - 18 Mar 1999 to 19 Mar 1999 - Special issue (#1999-87)
Date: Fri, 19 Mar 1999 10:11:29 -0500
From: Automatic digest processor 
Reply-To: MAX - Interactive Music/Multimedia Standard Environments
     
To: Recipients of MAX digests 

There are 12 messages totalling 711 lines in this issue.

Topics in this special issue:

  1. PowerBook - no floppy, what now? (2)
  2. Floppyless vision.
  3. Lots of questions. Any answers? (2)
  4. stamp (2)
  5. Alternate controllers, latency, and performance intimacy (2)
  6. stamp and midi
  7. using buffer~ loop sync
  8. new objects + patches on ircam ftp

----------------------------------------------------------------------

Date:    Fri, 19 Mar 1999 00:32:57 -0500
From:    Piotr Filipowski 
Subject: PowerBook - no floppy, what now?

Many of you are probably sick and tired of that topic but for me it is a
new and very real problem with which Opcode can not help me at this time.

How can I work around the authorization procedure without the additional
purchase of the "floppy thingy"? I have managed to authorize the drive
but the silly authorization procedure ignores that fact and demands the
floppy drive to be present.

Where can I find some help? I checked both Cycling'74 and Opcode sites
and still came up with nothing.

Thanks for any advice.

------------------------------

Date:    Fri, 19 Mar 1999 08:05:16 +0000
From:    Trond Lossius 
Subject: Floppyless vision.

Hmmm... That subject sounds better than I first thought...

Anyway, Vision DSP and Studio Vision Pro is now available with a
challenge/response authorizing scheme as an alternative to the floppy
key disc. As these are Opcode products as well, I guess there are good
reasons for pushing Opcode to do the same for Max.

Cheers!

Trond L.

------------------------------

Date:    Fri, 19 Mar 1999 16:37:35 +1030
From:    Ross Bencina 
Subject: Re: Lots of questions. Any answers?

Sukandar Kartadinata writes:

>>Anyone using homegrown microprocessor-based soloutions? (e.g.
>>Basic Stamp or Motorolla HC11 type stuff?) Any recommendations?
>
>I'd recommend the Basic Stamp for its steep learning curve. It's great to
>get simple things done quick. I also program the PICs (which the Basic
>Stamp is based on) in assembler to achieve better performance and for the
>smaller size. The (18-pin) 16F84 in particular is convenient because it has
>EEPROM program memory, so it's easily updated even in-circuit.

don't you mean shallow learning curve? UNIX has a steep learing curve :)

Recently I was considering buying one of those over priced MIDI knob boxes -
instead I built one for under $100 (Australian) using a PIC16F84. A month
ago I'd barely heard of the PIC chips - admittedly I have a few years
programming experience. I think the development tools for PIC chips are more
available on the PC than the Mac though.

For people with some electronics and/or programming experience and lots of
time to spend surfing the web looking for info I'd definitely recommend
building your own midi controllers using the PIC16f84. The main reason I
didn't use the Basic Stamp is that it costs more if you intend to use more
than one (it cost me about the same as 1 basic stamp to buy a few 16f84s, a
programmer kit, a power supply, a new soldering iron and a multimeter).
There are probably good reasons to use the Basic Stamp, especially if you're
not into learning assembley language.

BTW does anyone know of any sites that maintain links for DIY MIDI
controllers?

Ross.

------------------------------

Date:    Fri, 19 Mar 1999 01:27:57 -0500
From:    Jeff Mann 
Subject: Re: stamp

David Bianciardi  wrote:
> we use the PIC 16Cxx from microchip.  programmers (picstart plus from
...
> midi i/o works great.

David, do you have any PIC code for MIDI I/O that you could share?

Garth Paine  wrote:
> Can someone point me at a URL that explains the use of the "stamp" for
> sensor input, MIDI output.

I've e-mailed you my Stamp code for MIDI that I posted here a while
back. Others can check the Max list archive if interested. It shows how
to read resistive sensors like pots, faders, photocells, etc. and send
MIDI data. You can also look on the web for example code on how to hook
up an ADC0838 8-channel 8-bit A-to-D converter to it (I'll post my code
for that too when I get a chance). There's also a 12-bit converter you
could use, ADC12138.

The fact that the Stamp can't receive MIDI is not so much due to its
speed, but the fact that its serial port is done in software and is
unbuffered, and that there are no interrupts or multitasking functions
available. The new faster Stamp SX doesn't improve the situation.

There's also a new PIC chip which should be available in a month or two,
with 8k of flash ram, a real buffered serial port, and 8 channels of
10-bit A-to-D. Watch out I-Cube!


mailto:jefman@utcc.utoronto.ca ||   http://www.interlog.com/~jefman
Visit the Art & Robotics Group site: http://www.interaccess.org/arg

------------------------------

Date:    Thu, 18 Mar 1999 23:03:02 -0800
From:    Charles Baker 
Subject: Alternate controllers, latency, and performance intimacy

    Dear Max list -

I have been toying with the idea of obtaining some alternative
controllers such as
the aforementioned i-Cube and the STEIM SensorLab gear...but in talking
(actual
voice conversation!) with an experieinced Maxer who had worked with some
of
this gear, and he warned me of latency problems with many of the
sensors....
which might be ok for large scale installation and cross-discipline
(dance performance, etc.)
but as a (soprano) wind instrument performer one thing I always look for
in
an instrument is "response". I use a Peavey 1600X Midi fader box
( as well as a small keyboard and  a Midi wind controller).
These devices have passable "response" , although both the mechanically
excellent
faders of the Peavey and the wind controller still reveal the audible
"quantizing" of Midi's 7-bit data values on continuous data.
Because of shared dislike for  latency in  controllers,
this fellow Maxer (also a soprano wind instrumentalist BTW)
warned me against these commercial interfaces, as well as the much
disscussed
powerglove/goldbrick (& yes, I too found a cheap powerglove
& would love to have a goldbrick, sigh)
(He has a custom built glove & interface that he uses)
The point of this rant: please, some other user experience? Is there bad
latency ?
Although obviously for some musical paradigms such small latency is
perfectly acceptable,
I want to  be aware of what I am considering investing in.
Oh, and PS, I should be uploading my old "matrix" and "iso" objects in
fat format,
as soon as I figger out why one of the messages stopped working
last night as I finished the help file...*doh*!
CharlieB

------------------------------

Date:    Fri, 19 Mar 1999 09:41:00 +0100
From:    hc gilje 
Subject: stamp and midi

I have done some basic testing using basic stamp two and a MIDI
interface, with success, based on Jeff Manns instructions. If the ASCII
art is unclear the connections to the stamp is as follows:

pin 4 of MIDI plug via a 220 ohm restor to +5V on the stamp

pin 2 of MIDI plug directly to GND on stamp

pin 5 of MIDI plug via a 220 resistor to one the datapins on the
stamp.

Some genereal useful info on using the stamp, though a bit outdated:

http://fargo.itp.tsoa.nyu.edu/~dano/physical/physical.html

The Handyboard by Fred Martin can also be used for MIDI control, both
in and out:

http://lcs.www.media.mit.edu/groups/el/projects/handy-board/

with this  MIDI library made by Colby:

http://music.dartmouth.edu/~colby/hb.html

Here follows Jeff Manns isntructions and program for using the stamp
with MIDI

Hope this helps,

hc

'MIDI out program for BASIC Stamp II. Stamp I not fast
enough for MIDI.

'Stamps can't receive MIDI in because serial port is unbuffered.

'Copyright 1997-98 Jeff Mann jefman@utcc.utoronto.ca

'free for non-commercial use - may not be published.

'This program measures up to 15 potentiometers or other

'resistive sensors, and sends out 7- or 14-bit MIDI controller data.

'Easily modified to send note or pitchbend data instead. The values

'are not normalized to full-scale; you'll have to add code for that

'or do it in the receving program, eg. Max., taking into account the

'particular sensor you're using.

'

'                 rear view of MIDI out jack

'                     ___   ___

'     +5 volts       /   l_l   \

'      |            /           \

'      |         NC l o1     3o  l NC

'      |            \  o4 2 5o  /

'      |__/\/\/______\_|  o  |_/___/\/\/_____> to Stamp data pin

'         220 ohms    \___|___/     220 ohms

'                         |

'                        _l_

'                        ///

'                      ground

'

'

'Comment out DEBUG statments for faster response.

'constants, shouldn't change these

midibaudmode con 32780  '31.25kb, 8n1, non-inverted, open collector

'for 14-bit controllers - controller 32 is lsb of controller 0, etc.

controllerLSBoffset con 32

'MIDI status bytes:

controller con %10110000 + midichannel

noteon con %10010000 + midichannel

pitchbend con %11100000 + midichannel

'declare variables

value var word          'holds the 16-bit value read from the pot

pin var nib             'which pin/pot we are reading at the moment

statusbyte var byte     'MIDI status; controller, noteon, or pitchbend

data1 var byte          'first data byte, eg. controller or note
number

data2 var byte          'second MIDI data byte, eg. value or velocity

'user configuration - adjust these to suit you

'DANGER - check your circuitry and configure pins accordingly!!

'set unused pins to outputs

DIRS =3D3D %1111111111111111 'all outs

OUTS =3D3D %0000000000000000 'all low

midichannel con 1       'MIDI transmit channel

midioutpin con 0        'pin connected to MIDI out connector

'check the MIDI spec for a list of controller numbers you can use

controlleroffset con 0  'add to pot's pin # to get MIDI controller #

hipot con 15            'highest pin with a pot to measure

lowpot con 14           'lowest pin with a pot to measure

doit:

   debug HOME

   for pin =3D3D lowpot to hipot

     'read the value of the pot

     high pin

     pause 1

     rctime pin, 1, value

     debug "pot ", DEC pin, " reads ", DEC value, CR

     value =3D3D value >> 1      'drop the least significant bit

     'send most significant 7 bits as continuous controller msg

     statusbyte =3D3D controller         'sending controller message

     data1 =3D3D pin + controlleroffset  'controller #

     data2 =3D3D value.highbyte

     serout midioutpin, midibaudmode, [statusbyte, data1, data2]

     ''uncomment this section to send 14-bit controller data

     ''send least significant 7 bits

     'data1 =3D3D data1 + controllerLSBoffset

     'data2 =3D3D value.lowbyte

     'data2 =3D3D data2 >> 1     'convert to 7 bits

     ''use running status byte (can leave it out if unchanged)

     'serout midioutpin, midibaudmode, [data1, data2]

   next

goto doit


piXel

Hans Christian Gilje

Nedre M=F8llenberggt 9

N-7014 Trondheim

Norway

mob.93497088

http://kit.trdkunst.no/stud/hc

mailto:hcg@trdkunst.no

mailto:hc@pobox.com

------------------------------

Date:    Fri, 19 Mar 1999 11:06:53 +0100
From:    Benjamin Thigpen 
Subject: Re: using buffer~ loop sync

Hi,

david stevens wrote:

>i'm trying to get various parts of my patcher to synchronise by using the
>loopsync output of various buffer~s.  The problem is that the ramp is at 0
>and 1
>for such a short time that it's diffcult to detect either one reliably. the
>following patchette is how i've done it, and it works fairly well - but i'm
>hoping that there's a more reliable/elegant way of using loopsync outputs.
any
>thoughts, anyone?

Try this:

max v2;
#N vpatcher 352 76 514 246;
#P newex 89 93 37 196617 edge~;
#P button 89 116 15 0;
#P newex 89 70 43 196617 >~ 0.99;
#P newex 48 70 36 196617 ==~ 0;
#P button 48 116 15 0;
#P newex 48 93 37 196617 edge~;
#P newex 13 33 65 196617 groove~ loop;
#P connect 3 0 1 0;
#P connect 6 0 5 0;
#P connect 1 0 2 0;
#P connect 0 1 3 0;
#P connect 4 0 6 0;
#P connect 0 1 4 0;
#P pop;

Ben

------------------------------

Date:    Fri, 19 Mar 1999 13:19:22 +0100
From:    Manuel Poletti 
Subject: new objects + patches on ircam ftp

With a slight long delay, following max stuff can now be found on Irc. ftp

**************************************************

about "BulkStore":

Tom Mays wrote (14 Feb):

>With all this talk about presets and colls for variable storage, I got
>inspired
>to upload a storage system I developed a few years ago that some of you
>might find interesting. It's based on coll and it's called BulkStore.
>You can write your variable "preset" files
>to disk or just leave them as "save with patcher". Each line of a coll
>represents
>1 preset, so this is not for patchers with thousands of variables. Each
>variable
>is stored in the coll *with* its name, so there's complete flexibility in
>variable adding and subtracting - without having to midify your storage
>format.
>
>Open patcher *Bulkstore_example.pat for a more complete explanation.



**************************************************

about "HarmonaTon":

A playing msp application by Jim Wood so called  'HarmonaTon', wich allows
travelling graphically across some harmonic/enharmonic fields (I hope, Jim,
that you like the description):



I'd suggest a 'record' feature to be added.

**************************************************

about "The Musician's Guide to MIDI", by Walid Breidi - who wrote:

"...the general idea is to explain the MIDI system in a simple and intuitif
way.For this purpose I used color and the automatic mode (including the
user's mode) of displaying MIDI messages..."



**************************************************

enjoy !

_M

------------------------------

Date:    Fri, 19 Mar 1999 09:10:39 -0500
From:    Christopher Murtagh 
Subject: Re: PowerBook - no floppy, what now?

On Fri, 19 Mar 1999, Piotr Filipowski wrote:
>
> How can I work around the authorization procedure without the additional
> purchase of the "floppy thingy"? I have managed to authorize the drive
> but the silly authorization procedure ignores that fact and demands the
> floppy drive to be present.

Actually, don't buy a floppy to try to authorize your drive. The USB
floppies are not PACE friendly (but can you blame them ? :)! A solution
would be to put the IDE drive in another IDE PPC (like the earlier G3s, or
a *choke* Performa), authorize the HD, and then put it back into your new
G3/iMac. Pain in the butt, but that should work.

> Where can I find some help? I checked both Cycling'74 and Opcode sites
> and still came up with nothing.

Actually you can get floppyless authorization if you buy MAX/MSP from
Cycling74. This is what I would recommend.

Cheers,

Chris

-----------------------------------
Failure is not an option. In order to better serve the client, it has been
bundled with Windows98.

------------------------------

Date:    Fri, 19 Mar 1999 15:48:13 +0100
From:    Sukandar Kartadinata 
Subject: Re: Alternate controllers, latency, and performance intimacy

>this gear, and he warned me of latency problems with many of the
>sensors....

I know what you mean.

The SensorLab's nice because you can upload the event scheduling list to
its battery-buffered RAM, so you don't need a computer on stage. However,
its CPU power is limited, so there are cases where performance breaks down.
Also, the script language is kinda limited, and then there was a problem
with the ADC resolution which I don't know if it was fixed.

The iCube has better resolution and is cheaper. The problem is (and please
correct me if a newer version has fixed this) that it sends all the raw
values of the assigned analog inputs via MIDI and lets MAX figure out the
"intelligence part", so with many sensors connected this can slow down
things. When Axel Mulder gave me a demo of his sensor-glove, my feeling was
that a slight latency was perceivable.

Hacked Peaveys are great for some projects, but you're right - 7bit just
doesn't cut it at times.
The Powerglove/Goldbrick connects to the AdB (right?), so don't expect fast
performance here.

I should also note that some sensors have physical constraints that cause
latency, e.g. ultrasound for distance measurement

>Although obviously for some musical paradigms such small latency is
>perfectly acceptable

true. Latency is somewhat subjective. Guess you have to do some experiments
(e.g. play your instrument thru a delay line and headphones) to find out
what's acceptable for you. If you can get hands on a SLab or iCube and try
a few things.

>still reveal the audible
>"quantizing" of Midi's 7-bit data values on continuous data

bear in mind that the problem can also be the MIDI _destination_, i.e. your
synths&samplers&stuff, not only the MIDI source/controller. Maybe you'd
have to dismiss MIDI at all.

Anyway, if you DO need better latency, resolution, performance,
integration, etc. you could contact me - I design custom *ware for these
kinda cases.

ship ahoi,
S

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Sukandar Kartadinata
Custom Music Technology
Hagenauerstr. 6, 10435 Berlin, 030-44051219
http://members.xoom.com/Sukandar/
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

------------------------------

Date:    Fri, 19 Mar 1999 15:48:10 +0100
From:    Sukandar Kartadinata 
Subject: Re: Lots of questions. Any answers?

Ross Bencina writes:

>don't you mean shallow learning curve? UNIX has a steep learing curve :)
hmmm, guess it's all a matter of proper scaling ;)

>I think the development tools for PIC chips are more
>available on the PC than the Mac though.

yes, but what hardware development tools are available on the Mac anyway ?
OK, some work with serial ports, so you can mess around with
VirtualPC/SoftWindows, but most need parallel or ISA.

I agree what you said about the Basic Stamp. I prefer plain PICs, too.

>BTW does anyone know of any sites that maintain links for DIY MIDI
>controllers?

 been meaning to set one up for ages, but toomuchadoasusual

cheers,
S

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Sukandar Kartadinata
Custom Music Technology
Hagenauerstr. 6, 10435 Berlin, 030-44051219
http://members.xoom.com/Sukandar/
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

------------------------------

Date:    Fri, 19 Mar 1999 10:17:37 -0000
From:    David Bianciardi 
Subject: Re: stamp

On 3/19/99 6:26 AM, Jeff Mann wrote:

>David, do you have any PIC code for MIDI I/O that you could share?

sure.  i guess our m2s project is following in the footsteps of the great
ones, and going open source ;)....sort of.  I've emailed jeff a file that
compiles in MPLAB for the 16c74.  It's an old source listing from an
ongoing $$$ project, so I'm not comfortable giving out the final
application, but this should be useful for anyone trying to do MIDI on
pic chips.  If anyone else would like the same listing (it's an early,
buggy version, with no guarantees, support, etc ;) please email.  I
didn't spam the list with it, as C sprinkled with assembler has a certain
antiorpian quality which i'm sure would get me in trouble ;)

>The fact that the Stamp can't receive MIDI is....the fact that...there are
no
interrupts

understood, and agreed.  the lack of interrupts is the big bummer.  i did
figure, however, that if 1) the main loop was well written to poll as
often as possible (using a pseudo multitasking prioritized task loop),
and 2) the MIDI input was note ons or other short messages and not to
frequent, that a speedier processor might do a better (but still without
"guaranteed" reception) job.

One thing I've done to get around this in doing serial in to the stamp is
to have the transmitter constantly refreshing the message...ugly, but ok
in some circumstances.

David Bianciardi
tech@idrc.com

212.353.9087
212.353.3947 fax
______________________________________________
IDRC || 415 Lafayette St || NYC, NY 10003-7000

------------------------------

End of MAX Digest - 18 Mar 1999 to 19 Mar 1999 - Special issue (#1999-87)
*************************************************************************