URGENT : sfplay~ and RAM
Hi Cycling,
I'm experimenting strange RAM behaviour while using sfplay~ in
multichannel mode :
whatever the number of channels is - 4, 8, 6, 12 or 16 - , when I
preload several soundfiles into sfplay cues, and start playing each
cue sequentially, the RAM used by MSP is continuously increasing,
once the preloaded part of the sound has been read (cf "top" in
Terminal app).
As I loop the sequence of cues, the free RAM gets soon totally
fullfilled, then, soon or later, Max simply quits - no crash log or so.
It looks like sfplay~ continuously "preloads" the part of sound it
has to play, without ever clearing the already-read part from the RAM.
Of course, I've tried, changing buffer size, using sflist~, splitting
soundfiles in smaller formats, installing a new system, on several
machines, downgrading Max to earlier versions, etc : same behaviour.
Thank you for a quick help from Cycling developers, we're several
here to experiment LOTS of problems with sfplay~ in general, and THIS
OBJECT IS TOO IMPORTANT for live performances (some are thinking
using readsf~ from PD, via flext - cool).
I have now a new sound installation wich cannot run safely, due to that.
We must know if we can finally trust or not a simple multichannel
soundfile player in Max - or should we use f%$#@#@ sequencer ?
Thanks,
- and sorry, no time to google the site...
_M
Precision :
same behavior with :
- G5 bipro 2GHz (several), G4 Powerbook 17"
- OS 10.4.5, OS 10.4.6
- Max 4.5.4, 4.5.5, 4.5.6, 4.5.7
- sfplay~ 1, 2, 4, 6, 8, 12, 16, using either [preload cueID] or
[open, 1] messages - different buffer sizes
- use sflist~ to preload the files, then access them with named sfplay~
- internal HD, external HD, boot from external HD (brand new OS 10.4.6)
...
It looks that Max never frees the RAM sfplay~ uses, rather it is sent
to "inactive memory", according to terminal.
So, in fact, it is like sfplay loads slowly the entire soundfiles
into RAM.
As soon as the entire RAM is handled by Max, if I try something using
another trhead (a network access, for instance), the audio starts
clicking, I get random delays between the different tracks from the
soundfile, etc., then crash.
Please help - I can't buy 5 Gb of RAM to solve the problem...
Hi,
please can you post a patch showing this behaviour ?
I too have experienced this same behaviour but only in certain patches
(for example inside lloopp).
I have not been able to show to Joshua an evidence of the problem
All the best
Alessandro Fogar
Hi,
just open sfplay~.help, load a long soundfile, play it and watch the
RAM percentage in Terminal.
Takes time if the sfplay~ is mono until the free RAM is empty (the
more channels the fastest).
Take several soundfiles to make a full test, since it seems that Max
keeps track of preloaded files until you instanciate the object
again, or quit Max.
>
> Take several soundfiles to make a full test, since it seems that
> Max keeps track of preloaded files until you instanciate the object
> again, or quit Max.
Sorry, quitting is not enough - you must RESTART the machine so that
Max loses track of the old preloaded file.
C'mon...
Hello Manuel,
I made several tests here with LightRegie120x and its sound files
reader.
You are absolutely right, available ram decreases during playback. The
mac must be restarted to recover RAM.
I noticed this does not happend when you repeat a file, it's just with
"new" ones.
I finally - at that time- used the sflist~ option since I was never
lucky with sfplay~ by itself: too many inpredictable crashes.
I could simply not imagine a soundtrack abruptly stop during a theater
performance... At this time, it works but in theater conditions, since
soundtrack is not the most important thing, thanks to actors ;-)
I use a G4 PWB 1.25 gHz / 1.25 Go ram/ Mac OSX 10.3.9 & a 1 Go USB2 key
for files. The current version of LR120x use the last available version
of MaxMSP.
I finally made some tests with a jit.qt.movie object wich can play aif
files: the phenomenon does not happen. Maybe a short term alternative
for you?
Best,
Philippe
Hi,
we already talked about this here:
https://cycling74.com/forums/index.php?t=tree&th=1510 9
All the best
Alessandro Fogar
hi philippe / Manuel
I made several tests too and have the same sfplay~ behaviour.
I use a G4 PWB 1.25 gHz / 1.25 Go ram/ Mac OSX 10.4.6 /Max 4.5.7.
Same bug whith build app.
using jit.qt.movie is not a "MSP" alternative.
using a seq. like Live, with a Max patch is a good idea to become crazy!
So, I need a simple way to play SFiles. is it so hard to do ?
Hope someone will solve sfplay~'S problemS.
maybe at IRCAM....
best,
Francois
while i never had this problem before, yesterday it hit on me in its
full glory.
a mildly complicated patch (mostly graphic stuff) for a 5.1.
installation setup completely started to screw up the machine. (last
days i hadnt had time to read the list, so i wasnt warned what could
be going wrong).
the things is: playing a 6 channel-.aif-file starts shifting the ram
to "inactive" (as seen in terminal "top"), which is never freed.
after playing a couple of those files, of course, paging starts and
then things go really bad. increasing diskbuffersize was no help.
what drove me nuts is, that it only occurs on the installation-
machine (a minmac 1.42 ghz, 10.4.6, 512mb ram, max/msp/jitter
runtime/ demo-mode 4.5.7).
with the same patch on my pb (1.5 ghz, 1.5 g ram, 10.4.6 max/msp/
jitter) this behaviour doesnt occur.
strange.
even stranger: out of curiosity i made a simple pd-patch for playing
the same multichannel-files. same problem on the minimac, no problem
on the pb.
so it seems to be some bad system voodo rather than max alone.
my clumsy workaround: with the shell object i keep an eye on the free
ram. whenever it goes below a certain threshold, audio is stopped and
a buffer of approximately the size of the inactive memory is scripted
and then immediately destroyed. this frees the ram again (of course,
paging also happens, but it isnt that bad as before. tests still
running).
but still: what is it, that simply playing back audio-files can be
such a hassle???
puzzled
hans
p.s.: the patch to reproduce (or not) is so simple, taht i barely
dont dare to attach, but anyway:
hans w. koch
im krahnenhof 11
d-50668 koeln
+49-221-554902
www.hans-w-koch.net
On Jun 15, 2006, at 10:08 PM, Joshua Kit Clayton wrote:
> We will of course look into (don't expect an *urgent* fix by some
> deadline imposed by your projects, however, as we have many
> priorities and this is surely not our topmost).
Sorry ?
My project is certainly not a priority, but I would like to know if I
can trust soundfiles to be played on a computer with Max or not.
For the time being, it seems that I could save the installation by
adding 4 Gb of RAM (soundfiles take 3.5 Gb).
Fortunately, I didn't have to pull out the money from my own pocket -
fortunately too, I could take enough time to track the problem (be
sure that I wouldn't ring the support before at least 3 full days of
hard debugging), as I'm still a (temporar) employee.
As mentionned by another user, discussions around this topic started
in 2004.
if playing sounds with Max safely is not your topmost priority, I'm
very curious to know in wich position in the list comes the present
and future of doing audio with Max.
> Also note that cues remain resident in RAM. If you just generate
> more and more cues, they each will require the preload amount in
> RAM (for the *lifetime* of the cue). Replacing an existing cue
> number will free it and load a new one in place. However if you are
> just increasing cue numbers. RAM *will* grow without bound.
I only generate 12 cues in 2 sfplay~ object (so, 24 cues) using the
[preload cue-number filename] message.
Sfplay~ have an argument of 12 tracks, and the 60480 recommended
value (.help) for the buffer size argument.
Soundfiles have a length around 2mn each, each output is connected to
a dac-number.
Then I play those 24 cues one after the other, using an int
corresponding to the cue-number.
The total length of the loop is about 48 mn, wich is repeated from 11
a.m to 22 p.m.
That's all what I'm doing there.
> As for cue list looping leading to VRAM issues (including in a
> multi-channel setting), I've attached the following patch which
> does n cause RAM to grow without bound on my machine 10.4.7. Does
> this patch grow without bound for you, Manuel?
As far as I can see, no.
Have a look on the patch issued from mine (maybe generate a 12 tracks
soundfile - I've put a small recorder inside - and replace the
filenames with yours).
This one does.
Thank you,
_Manuel
If I recall correctly it was I who instigated a lot the discussion
regarding the problems with sfplay~. Mainly it not playing without a
second trigger. I found the main cause to be drive speed. It was
running on a powerbook at the time, moving all the audio onto a fast
firewire drive cured it for me, but I did end up using Live for all
critical audio just for safetys sake.
My apologies if this has already been suggested as I haven't been
following the thread.
Peas
Dom
> Hope someone will solve sfplay~'S problemS.
> maybe at IRCAM....
a good joke ?-)
On Jun 16, 2006, at 8:20 AM, Dominic Melville wrote:
> If I recall correctly it was I who instigated a lot the discussion
> regarding the problems with sfplay~. Mainly it not playing without
> a second trigger. I found the main cause to be drive speed. It was
> running on a powerbook at the time, moving all the audio onto a
> fast firewire drive cured it for me, but I did end up using Live
> for all critical audio just for safetys sake.
This is a different issue. That problem you are referring to is that
you need to disable HD sleep, or make sure the preload buffer is
large enough to wait for HD wake-up.
-Joshua
On Jun 16, 2006, at 5:21 AM, Manuel Poletti wrote:
> As mentionned by another user, discussions around this topic
> started in 2004.
> if playing sounds with Max safely is not your topmost priority, I'm
> very curious to know in wich position in the list comes the present
> and future of doing audio with Max.
In case it's not obvious, we are committed to providing as robust and
reliable audio features as possible. Unfortunately, as far as we can
verify, Max is working properly in this regard. So it is for marginal
cases (which we are unable to verify) which this is an issue. I
appreciate your frustration, but while soundfile playback from disk
might seem to be a simple and fundamental operation to you, it is
actually quite complex, especially with sample accurate cue
triggering and looping, variable speed playback, management of
arbitrary channel/bitdepth/ sample rate sound files in the same
circular buffer fed from disk, not to mention taking into account
everything that happens under the hood in the OS with respect to
memory management, disk access, and file I/O (which, as far as I can
tell, sounds like where these sorts of reports are having a problem).
Thank you for the clear example. These are always recommended for any
reports.
After initial preload of 11 cues of 12 channel pink noise files
(10-15 seconds each):
17846 MaxMSP 19.2% 2:12.15 22 651 694 32.6M 35.5M
51.0M 830M
After playback for several repetitions we have no signs of any
increase in RAM usage:
17846 MaxMSP 20.0% 16:43.68 22 652 694 32.7M 35.6M
50.9M 830M
I also don't see the inactive RAM steadily growing as Hans Koch
reported on the MacMini using either MaxMSP or PD. It just fluctuates
within a 16MB range.
I'll leave in the background playing longer, but this leads me to
think that it is an OS issue as had been discussed in the previous
thread, and as suggested by Hans Koch's post on the subject. I'll try
to do a bit more research on how this might be the case, but, until
we can establish the problem, we can't fix it. Even if we do
establish the problem, it sounds like it might be in the OS and out
of our control. Hans' fix for the inactive memory is also a curious
one, seemingly related to the memory manager's inner workings rather
than anything in MaxMSP's code.
-Joshua
> In case it's not obvious, we are committed to providing as robust
> and reliable audio features as possible.
It is - I've experimented too many local cases where this kind of
sentence had to be understood as a legend, to not appreciate the
responsiveness here.
That's why I now use external pattented software (since 1997...).
But it's hard for me to hear that audio playback is not a prior
feature to be fixed in a software that is intended to produce audio.
Numerous twisted real time/interactive/stochastic... anyway bloody
projects could be saved in the last minute using the old good "tape".
That's what I hoped I could do using sfplay~.
> Unfortunately, as far as we can verify, Max is working properly in
> this regard. So it is for marginal cases (which we are unable to
> verify) which this is an issue. I appreciate your frustration, but
> while soundfile playback from disk might seem to be a simple and
> fundamental operation to you, it is actually quite complex,
> especially with sample accurate cue triggering and looping,
> variable speed playback, management of arbitrary channel/bitdepth/
> sample rate sound files in the same circular buffer fed from disk,
> not to mention taking into account everything that happens under
> the hood in the OS with respect to memory management, disk access,
> and file I/O (which, as far as I can tell, sounds like where these
> sorts of reports are having a problem).
I fully understand that what seems obvious as a software feature
since Sound Accelerator & co appeared is hard to maintain over so
many versions of systems - especially when it has hundreds of
neighbours sitting in the same directory.
But, since 1997, it is no more a marginal idea for the happy Maxers
like me to intend to simply play looped multichannel files from a
patcher during a "serious" production.
So, excuse my surprise : if Digidesign couldn't handle soundfile
playback safely, they would be dead today.
It makes me remember "Jamais"-Max - wich disappeard ages ago - there
never were reliable soundfile playback...
> Thank you for the clear example. These are always recommended for
> any reports.
>
> After initial preload of 11 cues of 12 channel pink noise files
> (10-15 seconds each):
> 17846 MaxMSP 19.2% 2:12.15 22 651 694 32.6M 35.5M
> 51.0M 830M
>
> After playback for several repetitions we have no signs of any
> increase in RAM usage:
> 17846 MaxMSP 20.0% 16:43.68 22 652 694 32.7M 35.6M
> 50.9M 830M
Yes - Max seems to remain stable.
On my powerbook (so, another machine), when I load the test patch
(with soundfiles preloaded), top says :
Processes: 52 total, 2 running, 50 sleeping... 213
threads 12:36:05
Load Avg: 1.24, 0.65, 0.33 CPU usage: 23.7% user, 17.8% sys,
58.5% idle
SharedLibs: num = 177, resident = 41.9M code, 4.78M data, 8.99M
LinkEdit
MemRegions: num = 5172, resident = 133M + 10.3M private, 121M shared
PhysMem: 92.7M wired, 135M active, 238M inactive, 466M used,
557M free
VM: 5.02G + 109M 27643(0) pageins, 0(0) pageouts
283 MaxMSP 4.5 14.4% 1:12.18 26 804 605 38.3M 28.4M 51.8M
682M
After 10 minutes of playback, top displays :
Processes: 52 total, 3 running, 49 sleeping... 212
threads 12:45:40
Load Avg: 0.96, 1.04, 0.73 CPU usage: 33.3% user, 22.0% sys,
44.7% idle
SharedLibs: num = 177, resident = 38.0M code, 4.38M data, 6.15M
LinkEdit
MemRegions: num = 5143, resident = 133M + 10.3M private, 116M shared
PhysMem: 92.9M wired, 182M active, 735M inactive, 1011M used,
12.8M free
VM: 4.93G + 109M 27656(0) pageins, 58(6) pageouts
283 MaxMSP 4.5 22.4% 3:42.96 26 804 605 39.2M 26.7M
52.7M 682M
So, Max is OK, but the free RAM is put into inactive, and not "given
back" unless you restart the machine.
Then the proportions of RAM remain more or less like that.
If I run the files during hours, Max will crash soon or later.
Now, we've added 4 Gb of RAM - + the original 1.5 Gb, wich is enough
to fit the 3.5 Gb of soundfiles in RAM - free RAM (1.5 Gb) is
stabilized once the whole files are read entireley, and Max doesn't
crash anymore.
hi,
just joining in to confirm that there is more people out there having
the same problem - sfplay eating all the ram....
On 15.06.2006, at 22:08, Joshua Kit Clayton wrote:
> Replacing an existing cue number will free it and load a new one in
> place.
exactly this is not happening on my system (I have to reboot the
computer to get the ram back):
titanium 1 GHz, 10.3.8, max/msp 4.5.7
.....would be really great if there would be a fix sometimes......
best
noid
arnold haberl: noid@klingt.org
dornerplatz 13/32, a-1170 wien
+43-699-11 88 59 39
http://noid.klingt.org/
I stopped using sfplay~ in public performance several years ago due to unreliable playback (though it remains an excellent and valuable external for use in the studio). Instead I adopted the obvious solution of loading sounds into buffers for playback with groove~, but in that case of course you're limited by the amount of RAM on your machine.
Joshua's point is well-taken that unless the problem can be localized and made repeatable it is not easily solved. OTOH, on the same machine where I have had sfplay~ choke on a single stereo file (TiBook 1GHz, 512 MB RAM), I have never experienced a similar event from iTunes, or for that matter from Logic or Digital Performer. Or SoundHack. That suggests that, in theory, the problem could be solved. I'm not surprised that Pd gives similar performance, but it might still be worth checking if the SuperCollider or Csound disk file players prove more reliable.
In any case, even though this is reportedly a marginal problem (though of course it's not marginal if it happens on *your* machine, especially in front of an audience), it would be nice if a universally reliable solution were found, because soundfile playback is a core functionality. Maybe even worth redesigning sfplay~ from scratch.
Best,
Eric
Btw, I think we will be able to have this problem solved in the next
version of MaxMSP. It appears to be strange behavior in the File
Manager's caching implementation which is an issue only on some
machines (none of which I own). There are ways to avoid the File
Manager's cache implementation which we will use in the next version.
Thanks for your persistence in bringing this problem to our attention.
-Joshua
On Jun 17, 2006, at 11:40 AM, Eric Lyon wrote:
> Joshua's point is well-taken that unless the problem can be
> localized and made repeatable it is not easily solved. OTOH, on the
> same machine where I have had sfplay~ choke on a single stereo file
> (TiBook 1GHz, 512 MB RAM), I have never experienced a similar event
> from iTunes, or for that matter from Logic or Digital Performer.
Hi Eric,
The above sounds like the well known HD sleep problem often discussed
on the list (and solutions posted for). And yes, Logic, and other
applications which require a similar sort of real time delivery from
the HD in time to synchronize with the RAM preloaded to play the
region will stop playback in such an instance that the HD cannot wake
up and deliver audio in time. This happens to me all the time in
Logic when the HD goes to sleep...all playback stops and I get a
dialog about not being able to synchronize audio. You might not
notice this if you just launch the program and hit play, since in
such a setting, the disk is almost always active, but if you pause
with enough time for the disk to sleep, I believe you should be able
to reproduce(unless your disk buffers in Logic are large enough to
compensate for this behavior...same is true for sfplay~). Note that
this is not the case with Sound Hack or iTunes, since in those
applications it is permissible to simply start playback once the disk
becomes active.
One solution to this problem is to not let the HD go to sleep. It has
been discussed that while MaxMSP is running, it should not let the HD
go to sleep, which we could do. However, I'm not sure that this is a
universally acceptable solution since people use MaxMSP for a variety
of different needs and so this should be configurable (but if
configurable, you can already do so in the energy saver control
panel, or use a large enough diskbuffer size to accommodate the
slowest of HD wakeups).
-Joshua
my tests led me to the same conclusion, since i experienced the very
same behaviour with pure-data and vlc-player on a machine which
choked on sfplay.
the same patches run fine on another computer which has no problems
with sfplay either.
(see my post on this thread on june 16th)
weird it is.
hans
hans w. koch
im krahnenhof 11
d-50668 koeln
+49-221-554902
www.hans-w-koch.net
Hi,
consider that on my machine the sfplay~ inside a lloopp patch eats ram.
Instead, an sfplay~ inside the sfplay~.help or the patch submitted
some time ago by Noid does not eat Ram.
If you want I can provide patch examples.
All the best
Alessandro Fogar
Did this fix make it into the current 4.6 public Beta?
Also, do you have a list of the machines know to be problematic?
Many thanks,
Neal
Btw, I think we will be able to have this problem solved in the next
version of MaxMSP. It appears to be strange behavior in the File
Manager's caching implementation which is an issue only on some
machines (none of which I own). There are ways to avoid the File
Manager's cache implementation which we will use in the next version.
Thanks for your persistence in bringing this problem to our attention.
-Joshua
On Jul 24, 2006, at 4:32 AM, neal wrote:
> Did this fix make it into the current 4.6 public Beta?
Yes.
> Also, do you have a list of the machines know to be problematic?
It is not specifically a HW problem, but rather a software behavior
(Finder's File caching strategy) which we have no data that would
explain why it provides different behavior at different times. Seems
like it might be a bug or idiosyncrasy in Apple's algorithm for
determining how much and how long to cache file information. As
previously mentioned I've never been able to reproduce these problems
(meaning whatever voodoo that needs to be in place on my machine for
Apple's file caching to work the way I'd expect it to).
-Joshua
Excellent, will start to move over to 4.6. I know this has been a long-running thread, and a frustrating (non-c74) bug for you guys to fix... Thanks for the new version.
Neal
>
> > Did this fix make it into the current 4.6 public Beta?
>
> Yes.
>
On 6/17/06, Manuel Poletti wrote:
> On my powerbook (so, another machine), when I load the test patch (with
> soundfiles preloaded), top says :
>
> Processes: 52 total, 2 running, 50 sleeping... 213 threads
> 12:36:05
> Load Avg: 1.24, 0.65, 0.33 CPU usage: 23.7% user, 17.8% sys, 58.5%
> idle
> SharedLibs: num = 177, resident = 41.9M code, 4.78M data, 8.99M LinkEdit
> MemRegions: num = 5172, resident = 133M + 10.3M private, 121M shared
> PhysMem: 92.7M wired, 135M active, 238M inactive, 466M used, 557M free
> VM: 5.02G + 109M 27643(0) pageins, 0(0) pageouts
>
> 283 MaxMSP 4.5 14.4% 1:12.18 26 804 605 38.3M 28.4M 51.8M 682M
>
>
>
> After 10 minutes of playback, top displays :
>
> Processes: 52 total, 3 running, 49 sleeping... 212 threads
> 12:45:40
> Load Avg: 0.96, 1.04, 0.73 CPU usage: 33.3% user, 22.0% sys, 44.7%
> idle
> SharedLibs: num = 177, resident = 38.0M code, 4.38M data, 6.15M LinkEdit
> MemRegions: num = 5143, resident = 133M + 10.3M private, 116M shared
> PhysMem: 92.9M wired, 182M active, 735M inactive, 1011M used, 12.8M free
> VM: 4.93G + 109M 27656(0) pageins, 58(6) pageouts
>
> 283 MaxMSP 4.5 22.4% 3:42.96 26 804 605 39.2M 26.7M 52.7M 682M
>
>
> So, Max is OK, but the free RAM is put into inactive, and not "given back"
> unless you restart the machine.
I don't see why this is a problem. I don't use MacOS X much these
days, but on most modern *nix machines, this is normal behaviour. This
is just buffer cache and will be given up to an application the moment
it needs it.
Basically, what's happening is that the OS is being smart and storing
data into RAM since there's no real value in wiping it. If you ever
need that data again, it will already be in RAM, if you don't and need
the RAM, it is given up to the OS/Application. Unless the OS does
something dumb and starts swapping heavily (which doesn't seem to be
the case here), this is not a problem at all.
Cheers,
Chris
Hi,
Christopher Murtagh said:
> Unless the OS does
> something dumb and starts swapping heavily (which doesn't seem to be
> the case here), this is not a problem at all.
Yes, but this is the case, the OS DOES start swapping and audio dropouts occour.
Otherways why do you think that we did pose the problem ?
This is not something happening in OS theory this happens on our machines.
One year ago I had to rewrite one piece of mine cause this problem
(otherways I had to buy 2 Gb of Ram but I am not Ircam, you know :-)
) ...
Let's hope it is solved now...
Peace , all the best
Alessandro Fogar
On 7/25/06, Alessandro Fogar wrote:
> Hi,
>
> Christopher Murtagh said:
>
> > Unless the OS does
> > something dumb and starts swapping heavily (which doesn't seem to be
> > the case here), this is not a problem at all.
>
> Yes, but this is the case, the OS DOES start swapping and audio dropouts occour.
>
> Otherways why do you think that we did pose the problem ?
Oh, sorry. I didn't see this in the thread, but re-reading it now I
can see it. If this is the OS doing something dumb, this could be
pretty hard for the cycling74 guys to fix. Ahh, the joys of the
spinning lollipop - this is why I use Linux most of the time. :-)
If however, the sfplay~ object is *always* loading entire samples
into RAM regardless of their size (instead of buffering and loading as
needed - a much more complex but obviously necessary task for large
samples), it should be considered a limitation of the object. Using it
to play 1GB audio files would be the equivalent of transporting
elephants with a VW Bug. Perhaps it was just designed to handle short
audio samples by the original author and therefore it's a useage
and/or documentation problem? In either case a more appropriate object
would be needed, maybe one that's always loaded (for small samples)
and one that's buffered (for large files) would be the best approach?
Cheers,
Chris
On 25 Jul 2006, at 17:00, Christopher Murtagh wrote:
> If however, the sfplay~ object is *always* loading entire samples
> into RAM regardless of their size (instead of buffering and loading as
> needed - a much more complex but obviously necessary task for large
> samples), it should be considered a limitation of the object.
sfplay~ doesn't do this. It preloads and buffers some audio, and
operates by streaming.
-- N.
nick rothwell -- composition, systems, performance -- http://
www.cassiel.com
On 25-Jul-2006, at 17:00, Christopher Murtagh wrote:
> would be the equivalent of transporting
> elephants with a VW Bug
Oh, no! Not a revival of the "how many elephants can you get into a
VW Beetle" jokes. I hoped I heard the last one of those in 1967.
-- P.
-------------- 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
Wasn't that the Ultimate Question?
;-)
Trond
> Oh, no! Not a revival of the "how many elephants can you get into a VW
> Beetle" jokes. I hoped I heard the last one of those in 1967.