Discussion:
Csound and other synthesis systems
(too old to reply)
Michael Gogins
1999-06-16 12:26:42 UTC
Permalink
Again I mount my soapbox to rant about desired changes in Csound. Before you
say I just talk about them but don't do them, take note that I have done
some of them in AXCsound/JCsound, which are open source.

This particular rant is occasioned by my audition of Buzz and Generator.
Buzz, for those of you who don't follow software synthesis on the Web, is a
"tracker" synthesizer, and is free. Generator is a commercial modular
software synthesizer, and costs money. Both programs run on Windows. Other
programs of note that I don't talk about here are SuperCollider and
GrainWave.

Buzz is a software synthesizer for tracker files. The tracker files are
similar to MIDI files except that they can contain embedded sound samples.
It appears to be an idiosyncratic binary file format. I don't know where it
comes from (but I will find out). Buzz can be found at http://www.buzz2.com.
Buzz has a simple but effective graphical user interface for (a) editing
sequences, (b) editing loops for sequences, (c) cataloging samples, and last
but not least, (d) wiring unit generators together. The unit generators
(called "machines" generically or "generators" and "effects" for signal
sources and signal processors) are Windows DLLs, plugins in other words, and
can be written by anybody with the latest Microsoft compilers; they have a
fairly simple design. Buzz automatically generates their simple-minded
little GUIs for them.

Buzz has an active community including developers of plugins as well as
composers of songs, with a number of Web sites, you can get CDs containing
tracker files and machines, and the thing actually sounds pretty good (it
uses DirectX sound drivers and can accept soundfile input and write
soundfile output as well as play in real time). There is no realtime MIDI
note on performance (although there are realtime MIDI control messages) and
no external API for programmatic control. Buzz's DSP capabilities have now
gotten as far as the Karplus-Strong plucked string and some pretty extensive
filtering, chorusing, delaying, and reverberating.

Generator is a software emulation of analog patch-cord synthesizers. It is a
very high quality product. It does low-latency real-time performance with
MIDI note on control, can read and write input and output soundfiles, and
has extensive facilities for user wiring of unit generators with a fancy,
fancy GUI that emulates a Moog-style modular synthesizer. Generator's DSP
facilities are very roughly comparable to Buzz's. Generator is VERY good at
making interactive patches (not as powerful as Max/MSP, but much easier to
"get" and use). Generator is planned to be able to act as a VST or ActiveX
plugin.

Currently, Csound offers substantially more musical capabilities than either
of these products, which probably are fairly representative of the current
state of the art, but it is looking increasingly creaky in the software
engineering department. Csound is particarly strong in score format,
time/frequency analysis and resynthesis, and physical modeling.

Csound would quickly fall to the rear of the class if (a) Buzz got note on
control and a simpler input file format, or (b) Generator got plugin unit
generators and a more flexible input file format. At that point, people like
me would scarf up Csound's unit generators and add them to a synthesizer
framework that is more functional and easier to use, resulting in a best of
breed musical instrument.

Csound could be put firmly back at the leading edge of the state of the art
if:

Csound gets plugin unit generators and function tables with a SIMPLE, I mean
REALLY simple, API.
Csound gets double-precision signal processing (Buzz and Generator use
floats).
Csound gets low-latency MIDI and audio input and output that works more or
less the same on its major platforms.
Csound gets an at least semi-snazzy GUI including unit generator wiring.
Csound gets an external API for programmatic control.
Csound can act as a VST plugin.

These features could be provided at moderate effort by:

Making Csound into the DSP kernel of a Java software synthesizer.
Evaluating JavaSound for all audio and MIDI input and output. Currently
JavaSound lacks MIDI input but some independent developers are working on
it.
Adapting Russell Pinkston's PatchWork program (16 bit Windows program) to
Java as a unit generator wiring form.
The VST part is easy.

What is needed here is a reasonable compromise between the power and
amenability for experimentation of a bare-bones piece of academic UNIX
software, and a user-friendly GUI and user-extensible plugin architecture,
with realtime performance AND non-realtime soundfile rendering. This is the
wonderful musical instrument that is evolving before our very eyes (and
ears), and Csound already contains all the necessary guts for the thing.







dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
Michel Jullian
1999-06-16 15:34:35 UTC
Permalink
Michael Gogins wrote:
<cut>
> Csound could be put firmly back at the leading edge of the state of the art
> if:
>
> Csound gets plugin unit generators and function tables with a SIMPLE, I mean
> REALLY simple, API.
> Csound gets double-precision signal processing (Buzz and Generator use
> floats).
> Csound gets low-latency MIDI and audio input and output that works more or
> less the same on its major platforms.
> Csound gets an at least semi-snazzy GUI including unit generator wiring.
> Csound gets an external API for programmatic control.
> Csound can act as a VST plugin.

This last point is _very_ good idea (the other points too). The VST 2 sdk,
featuring full midi control of plugin synths (AFAIK it's the only plugin
architecture with this feature) and a multiplatform GUI API, is due out any
day now (watch out for it on steinberg's vst devs list
<vst-***@steinberg.net>). Furthermore it is open not only to plugin
developers but also to host developers, which should help it become a standard.

What would be really nice would be if csound could "compile" orcs as vst
plugins, somehow, instead of (or as well as) acting as a vst plugin.

--
Greetings,
Michel
.........................................................................
Michel Jullian Directeur General email ***@exbang.com
Exbang Industries S.A.
Mas Chauvain route de Villeneuve tel +33(0) 499 529 878
Maurin 34970 Lattes France fax +33(0) 499 529 879
.........................................................................

dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
rdbr03035
1999-06-16 15:32:34 UTC
Permalink
I agree that, taken direfctly in the conext of newer softsynths, Csound
can look 'creaky', and it is indeed a tempting thought to revamp the
whole thing to exploit the best of modern GUI/Plugin techniques. I have
long thought about doing this myself 'as an exercise'. However, one
vital aspect of Csound it it's extremely wide cross-platform character;
and indeed it's core functionality as a console program has advantages
for visually-impaired users.

I don't think this could be done piece-meal. Basically, one would have
to take the score and orc syntax and create a new engine from scratch,
with multiple thread, dynamic libraries, and all the superstructure of a
modern GUI-based application.

Set against this is SAOL, which is ~fully~ public domain, and which is
open for adaptation in any number of ways, has a more up-to-date
language, and even has a means of compiling into a stand-alone
application, thanks to 'cfront'. The legacy of SAOL scores is also
arguably less significant, so compatibility at the command-line level is
scarcely an issue. After all, SAOL is expected to be embedded in set-top
boxes ere long!

In the end, it depends how stronly the moral imperative that Csound
~should~ be at the 'leading edge' as a functioning softsynth, in the
terms described. As it stands, it is a treasure-trove of dsp ideas, of
unique educational value, a feature that I value highly. The issue then
is one of modernity v fragmentation (unless it can be done exclusively
using Java and/or TCL/TK), an issue which simply does not arise for
SAOL. Csound ~is~ it's source code, but that is not strictly true of
SAOL - 'saolc' is merely an example implementation.

If we treat the score and orc syntax similarly, as a specification (as
we can reasonably do), there is no reason why some new program cannot be
written which implements it in a more modern form. The sticking point is
then the title (in the legal sense), as my understanding is that
ultimately this still belongs to MIT and Barry Vercoe.


Richard Dobson


Michel Jullian wrote:
>
> Michael Gogins wrote:
> <cut>
> > Csound could be put firmly back at the leading edge of the state of the art
> > if:
> >
> > Csound gets plugin unit generators and function tables with a SIMPLE, I mean
> > REALLY simple, API.
> > Csound gets double-precision signal processing (Buzz and Generator use
> > floats).
> > Csound gets low-latency MIDI and audio input and output that works more or
> > less the same on its major platforms.
> > Csound gets an at least semi-snazzy GUI including unit generator wiring.
> > Csound gets an external API for programmatic control.
> > Csound can act as a VST plugin.
>
> This last point is _very_ good idea (the other points too). The VST 2 sdk,
> featuring full midi control of plugin synths (AFAIK it's the only plugin
> architecture with this feature) and a multiplatform GUI API, is due out any
> day now (watch out for it on steinberg's vst devs list
> <vst-***@steinberg.net>). Furthermore it is open not only to plugin
> developers but also to host developers, which should help it become a standard.
>
> What would be really nice would be if csound could "compile" orcs as vst
> plugins, somehow, instead of (or as well as) acting as a vst plugin.
>
> --
> Greetings,
> Michel
> .........................................................................
> Michel Jullian Directeur General email ***@exbang.com
> Exbang Industries S.A.
> Mas Chauvain route de Villeneuve tel +33(0) 499 529 878
> Maurin 34970 Lattes France fax +33(0) 499 529 879
> .........................................................................

dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
Michel Jullian
1999-06-17 14:42:43 UTC
Permalink
Job M. van Zuijlen wrote:
>
> If we're talking plug-ins, I would like the approach to be a little bit
> more general than Steinberg's VST. I do not and do not want to use
> Steinberg products, so VST support would be of no interest to me.

as I wrote (see below), the architecture is open to other hosts than
Steinberg's, which makes it of interest to virtually anybody. Emagic's Logic,
and many other existing or future sequencers or audio softwares host VST plugins.

In fact I believe it makes sense nowadays to release any soft synth or effect
in the form of two components :
- a (small) audio engine app for standalone use (can be the same for any synth
or effect)
- a (big) vst 2 plugin which may be used either by "its" engine app or, in a
much more efficient way than if it was a "full" app with its own audio
callbacks, by a sequencer.

> > <vst-***@steinberg.net>). Furthermore it is open not only to plugin
> > developers but also to host developers, which should help it become a standard.

--
Greetings,
Michel
.........................................................................
Michel Jullian Directeur General email ***@exbang.com
Exbang Industries S.A.
Mas Chauvain route de Villeneuve tel +33(0) 499 529 878
Maurin 34970 Lattes France fax +33(0) 499 529 879
.........................................................................


dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
Michel Jullian
1999-06-16 16:10:36 UTC
Permalink
Jim Stevenson wrote:
>
> Many of these suggestions would restrict csound to gui at best, and to
> windows gui at worst.
>
> Please *do not* lock out those of us who prefer or need commands to program!

Of course not. Allowing UG wiring via a GUI doesnt mean proscribing text
editing of orcs : GUI and text could just be 2 ways to edit an orc file, IMO.

As for the platform-specificity of the GUI, the author of these suggestions
Michael Gogins suggested coding it in Java. Why not, a GUI doesnt have to be
very fast.
--
Greetings,
Michel
.........................................................................
Michel Jullian Directeur General email ***@exbang.com
Exbang Industries S.A.
Mas Chauvain route de Villeneuve tel +33(0) 499 529 878
Maurin 34970 Lattes France fax +33(0) 499 529 879
.........................................................................


dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
James McCartney
1999-06-16 15:32:24 UTC
Permalink
At 6:26 AM -0600 6/16/99, Michael Gogins wrote:

>Other
>programs of note that I don't talk about here are SuperCollider and
>GrainWave.

OK, but...

>What is needed here is a reasonable compromise between the power and
>amenability for experimentation of a bare-bones piece of academic UNIX
>software, and a user-friendly GUI and user-extensible plugin architecture,
>with realtime performance AND non-realtime soundfile rendering. This is the
>wonderful musical instrument that is evolving before our very eyes (and
>ears), and Csound already contains all the necessary guts for the thing.

If expressive power is what you want then why go with Csound?

Csound : assembly language :: SuperCollider : Smalltalk

(OK this is crossposted to the Csound list so I can see those
flames rolling in.. 8-0 )

Seriously, I would be interested in any serious proposals for
collaboration on a port of SuperCollider to Linux.
I think a SuperCollider + GTK on Linux would be very cool.

SuperCollider was written from the beginning to be used in real time.
All operations were conceived and written with that in mind. For example
variable delay lines of any maximum length can be allocated and used
immediately without needing to be zeroed out first. (SC can do non
real time just fine too.)

Right now SC is closed source, however I have been considering
opening the source to the language virtual machine.
Plugins of UGens and language primitives are both possible.
SC was designed for easy plugging in of language primitives.
The virtual machine should be easily portable, there is no
Mac specific code in there.

--

SuperCollider is a dynamically typed, real time garbage collected,
fully object oriented language like Smalltalk with support for true closures,
coroutines, positional or keyword arguments, variable length argument
lists, default argument values, etc.
It has a class library of 341 classes including a full set
of Collection classes like Dictionary, Set, SortedList, etc.
There are currently over 200 unit generators.

--


--- james mccartney ***@audiosynth.com http://www.audiosynth.com
If you have a PowerMac check out SuperCollider2, a real time synth program:
<ftp://www.audiosynth.com/pub/updates/SC2.1.5.sea.hqx>





dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
Robin Whittle
1999-06-16 15:53:57 UTC
Permalink
Michael Gogins mounted his soapbox on the limitations of Csound. He
seemed to be focused on a Windows-based patchable-synthesiser view of
software synthesis.

Here's the view from my particular soapbox.

There is much more to software synthesis and Csound than being like a
Moog modular on MIDI, but such a thing would certainly be a marvel and
would be widely used, including by me!

There are those of us who do not want to run things on Windows if we
can help it. (I find Windows a seriously unreliable and frustrating
operating system, despite its creature comforts which I know and
love. I have no interest in owning a Mac - too expensive and weird.)
We want open-source free software which runs on an open-source
operating system - most obviously Linux. We want all the compilers
etc. to be open-source too.

See these sites for more on "free" and "open-source" software:

http://www.fsf.org/philosophy/philosophy.html

http://www.opensource.org

With a sufficiently motivated user community, the tools evolve well
and are typically the best available at any price.

This way, unless the code base is badly writen, we can modify and
extend the programs as we choose, and feed those improvements back
into the mainstream versions of that program. This is what has been
done with Csound in recent years (with John Fitch doing a lot of the
work), but there are limits beyond which it cannot be improved or
changed.

Don't even think about any significant changes to the Csound code
base. Many who have looked closely at it have come away shaking their
heads. It works at what it does. In many respects it is an elegant
and unbeatably fast system. Parts of it can be tweaked. However it
is not sufficiently well structured or well documented to allow any
major conceptual change in its operation - internally or in terms of
score, orchestra file, or unit-generator sructure. Although the
unit-generator concept is a highly object oriented approach, the code
itself is written in plain C (originally not ANSI C) to low standards
of internal documentation. Csound's copyright is more restrictive
than the the full GPL open-source arrangement which is being adopted
for many of the most significant software projects today.

The only attempt I am aware of to produce a Csound-compatible
real-time graphic and MIDI controlled software synthesis system is
Paul Barton-Davis' so-far solitary work on Quasimodo:

http://www.op.net/~pbd/quasimodo/

It is early days yet. I did get a sound out of it two days ago -
real-time GUI control of instrument parameters. This can be done via
MIDI too, and it can output MIDI and input sound too . . . Paul is
making rapid progress. We have just established a mailing list for
those who are interested. It is a "hackers only" source code release
- you have to compile it yourself, and there is a list of things you
need to install beforehand.

Quasimodo does not run on Windows or Mac and probably never will. It
is a multi-threaded application ready for symmetrical mulitprocessing
dual CPU machines (enabling the DSP stuff to run on one CPU and the
user interface to run on another). It uses the latest techniques in
C++ programming, including STL (Standard Container Library). My
initial impression is that the structure is sound and the code-writing
and documentation values are high.


There seem to be types of people who are interested in investing the
immense effort required to develop a usable software synthesis
language / GUI real-time-synth:

1 - People like Paul Barton-Davis, a few other people and probably me
who would only consider doing this in a purely open-source
arrangement, and therefore not to sell the program on the
shrink-wrap market. We rely on collaboration and other sources
of funds.

2 - Those who are prepared to develop their own products alone,
in Windows or Mac environments, and sell them to the masses
who currently typically prefer these types of computer.
These people need to raise capital, work alone, keep their
source code secret and be concerned about musicians pirating
their software. Their environment for software is not so
flash in many respects. They are generally dependent on
commercial compilers. Is the Mac ready for multiple CPUs?
Windows NT supposedly is - but it is a crash-prone as
Win98. They can only occasionally release updates to their
software, while open-source people can release updates
without any significant cost, delay or impediment.


Only two of Michael's suggestions seem practical to me:

> Csound gets low-latency MIDI and audio input and output that works
> more or less the same on its major platforms.

Hasn't this already been achieved by Gabriel Maldonado and John Fitch
in the standard version of Csound? What latency problems are there?
Csound is very tighly coded in its central loops. Maybe Windows
ActiveX (I don't really know what this is) can provide sufficiently
finely-diced and reliable CPU resources to make it run reliably with
short buffers.


> Adapting Russell Pinkston's PatchWork program (16 bit Windows
> program) to Java as a unit generator wiring form.

I guess such a patching system can be done in any language - but I
would much rather write orchestra code than muck around with a GUI on
that level! Patching instruments together, as Quasimodo does, with
the GUI interface for each instrument defined it its part of the
orchestra file . . . . yes I think can be very useful.


Personally I think the Csound orchestra and score language should be
left behind. If I was writing a system from scratch it would not use
any special language at all - it would be a special framework for
writing C++ to get on with real-time sound synthesis and all I/O and
GUI things you might like to hang of that. It would do non-real-time
work as well, and the same principles would probably apply to
generating video images too. The C++ core elements would interface to
things in other languages, for instance novel score languages or
whatever you liked to create.

I have a name for it: Topsy. I don't expect to start on it for some
years to come - because I am involved in other things, and the
knowlege I would require is immense: C++, STL, CORBA, GTK, SMP,
P-Threads, not to mention some more DSP theory . . . .

So I suggest looking at Quasimodo (and hence at Linux), or going
against the flow on Windows and Mac and attempting an open-source
project there.

For those who make bold proposals about super-charging Csound itself
with major changes to its functionality . . . did you ever see the
movie "Repo Man"? Remember what happened shortly after the policeman
is told "No . . . you don't want to look in the trunk!"?

- Robin


===============================================================

Robin Whittle ***@firstpr.com.au http://www.firstpr.com.au
Heidelberg Heights, Melbourne, Australia

First Principles Research and expression: Consulting and
technical writing. Music. Internet music
marketing. Telecommunications. Consumer
advocacy in telecommunications, especially
privacy. M-F relationships. Kinetic sculpture.

Real World Electronics and software for music including:
Interfaces Devil Fish mods for the TB-303, Akai sampler
memory and Csound synthesis software.

===============================================================

dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
pete moss
1999-06-16 17:53:35 UTC
Permalink
isnt that what cmusic does? except with c, (no ++).

:P


Robin Whittle wrote:
> Personally I think the Csound orchestra and score language should be
> left behind. If I was writing a system from scratch it would not use
> any special language at all - it would be a special framework for
> writing C++ to get on with real-time sound synthesis and all I/O and
> GUI things you might like to hang of that. It would do non-real-time
> work as well, and the same principles would probably apply to
> generating video images too. The C++ core elements would interface to
> things in other languages, for instance novel score languages or
> whatever you liked to create.

dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
Robin Whittle
1999-06-17 02:29:49 UTC
Permalink
Pete Moss pointed out that what I described as my long term plan (a
framework for C++ to support realtime synthesis) is akin to cmusic.

I think this is true. This post looks at what I understand about
cmusic and how it only produces a single sample of audio per ugen
call, compared to Csound which produces ksmps samples, and so can be
very much faster.

Looking at Dave Philip's marvellous link-farm on software synthesis:

http://www.bright.net/~dlphilp/linux_soundapps.html

leads me to Tim Thompson's venerable PLUM page on music languages,
which should be at:

http://www.nosuch.com/plum

but this file is absent at present. (I emailed Tim.)

Searching for "cmusic" is tricky, but I found something from 1994 at:

ftp://ccrma-ftp.stanford.edu/pub/cmusic/

I also found some descriptive text at:

http://www.gsu.edu/webfs01/mus/musrst/public_html/cara/courses/
Csound_Users_Seminar/acoustic.html

which states that cmusic was written in 1980 by F. R. (Dick) Moore.
Like Csound, cmusic's lineage is traceable to Music V.

Please correct me if I am wrong, but it is my understanding that both
Music V and cmusic call the code for a unit-generator, and that code
produces just one sample of audio output. Csound's distinguishing
characteristic is that it has a variable "ksmps" which tells the unit
generator how many samples to calculate. ksmps can be 1, but then
Csound runs rather slowly, as would Music V and cmusic. Generally
ksmps is 5 to 25 or so - and so the overhead of running the central
loops and calling unit generator functions is spread over the
production of many more audio samples.

Csound therefore has "k" and "a" rate signals, with the orchestra file
determining the ksmps rato between them. This makes for some ugly
complications trying to maintain and translate between two separate
kinds of variable, but it makes Csound run ***lots*** faster. This is
particularly true in "draft" mode where you set ksmps rather high to
test the composition out, albeit with lousy sound quality. When the
composition is complete, then set ksmps to 2 or 3 and leave the
computer cooking overnight to produce the final rendering.

Speed is absolutely crucial in this field, since computers are still
slow compared to the rich analogue world of zillion-path reverberation
which we know and love.

I remember trying to understand cmusic a few years ago, but I never
got very far. Perhaps it was because I discovered it could not run as
fast as Csound.

Does anyone have more information about cmusic?

Generally with other software synthesis programs I have looked, I lost
interest when I found that either they did not support ksmps samples
per call (this includes most programs and Kyma/Capybara
http://www.symbolicsound.com ), or they start with a particular
high-level model of what constitutes "music" which doesn't suit me.
Kyma looks amazing and is certainly an inspiration, but it runs on
specialised hardware, uses integers rather than floats and has a
limited memory capacity per CPU.


- Robin


===============================================================

Robin Whittle ***@firstpr.com.au http://www.firstpr.com.au
Heidelberg Heights, Melbourne, Australia

First Principles Research and expression: Consulting and
technical writing. Music. Internet music
marketing. Telecommunications. Consumer
advocacy in telecommunications, especially
privacy. M-F relationships. Kinetic sculpture.

Real World Electronics and software for music including:
Interfaces Devil Fish mods for the TB-303, Akai sampler
memory and Csound synthesis software.

===============================================================

dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
Larry Troxler
1999-06-17 01:04:08 UTC
Permalink
> Please correct me if I am wrong, but it is my understanding that both
> Music V and cmusic call the code for a unit-generator, and that code
> produces just one sample of audio output. Csound's distinguishing
> characteristic is that it has a variable "ksmps" which tells the unit
> generator how many samples to calculate. ksmps can be 1, but then
> Csound runs rather slowly, as would Music V and cmusic. Generally
> ksmps is 5 to 25 or so - and so the overhead of running the central
> loops and calling unit generator functions is spread over the
> production of many more audio samples.
>
> Csound therefore has "k" and "a" rate signals, with the orchestra file
> determining the ksmps rato between them. This makes for some ugly
> complications trying to maintain and translate between two separate
> kinds of variable, but it makes Csound run ***lots*** faster. This is
> particularly true in "draft" mode where you set ksmps rather high to
> test the composition out, albeit with lousy sound quality. When the
> composition is complete, then set ksmps to 2 or 3 and leave the
> computer cooking overnight to produce the final rendering.
>

Now this ksmps != asmps issue is something that I've always wondered
about, as far as performance. My first question, would be how many orcs
and scores require ksmps == 1? Isn't it a lot? The times I worked with
Csound, I often needed to set ksmps==1 to allow instruments that use
audio feedback to work properly. I don't mean cases where it just
wouldn't sound as good. I mean rather, any case where you use feeback,
in which case things won't work at all, unless you forget about multiple
ksmps per audio frame. Perhaps however, I am not enough Csound-aware to
know of all the work-arounds in certain situations to avoid having to
use ksamps==1. But it seems that *any* instruement in a composition that
uses audio feedback will require ksmps=1 to realize the entire
composition! (unless of course, Make or something similar is used,
togethre with audio mixer scripts, in which case Csound can be invoked
on a per-part basis, with the parts mixed together afterward)

I am actually quite surprised that use ksamps>1 results in "***lots***"
faster efficiency! Is this true for processors with tiny cache only
(this would make sense - run a tight, small loop in each ugen, which
will run entirely in cache) , or does it somehow also result in
improvements for situations where the entire audio chain can be cached?

But to get to my point - assuming that there are indeed a lot of cases
where you need ksmps==1, then doesn't this result in some serious
innefficiency for this common case? Don't all the audio ugens need to
use a loop to process all thee samples in one ksmps-size buffer? And for
the common case where ksmps==1, you would think that this would be
horribly slow compare to an implementation where the ugens would not
loop, but simply process one sample (or better yet, Csound would
generate C code to implement each instrument - ala CLM)

What am I missing here? Is it just accepted that Csound isn't exactly
built for speed, but is enticing to use because of its large opcode
seleection?


Larry


dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
Robin Whittle
1999-06-17 04:18:11 UTC
Permalink
I agree with what Larry Troxler wrote about how important it is for
ksmps to be 1 in some applications - particularly those involving
audio feedback.

Ideally a system would enable some parts to be executed with various
ksmps rates. It is a tall order, and the sort of thing I am
contemplating for "Topsy" which is pure vapour-ware at present and
likely to remain so for several years at least.


Larger ksmps values certainly does speed calculations!

In one elaborate Csound piece I did in 1996 (admittedly this was on a
100MHz AMD 486) ksmps=10 was 2.1 times faster than ksmps=3. Life is
too short to try this at ksmps=1, since it took 36 hours to cook at my
final rendering quality of ksmps=3. The piece had a mix of general
simple Csound ugens and extensive use of a very large ugen of my own.

For me, there are enough things which can be done with ksmps > 1 to
make it worth the trouble. It is easy to dream of complexities of
sound creation and reverberation which would tie up any amount of
computing resources - so processing speed directly translates into the
final sonic sophistication of the music and/or the ability of the
composer to run it time and again whilst refining it.

For instance I figured out how many paths of sound reach the head in a
rectangular room, from a single source, allowing for direct, single
wall, two wall, etc. up to six wall reflections. Not counting the
sound hitting the same wall twice (and therefore not counting real
reverberation), there were about 1956 paths - each which would ideally
be processed by a CPU intensive binaural algorithm.

The physical world is a very rich place, and if we want to do anything
of similar finesse on a CPU, it is worth finding the fastest way of
doing it.

- Robin



===============================================================

Robin Whittle ***@firstpr.com.au http://www.firstpr.com.au
Heidelberg Heights, Melbourne, Australia

First Principles Research and expression: Consulting and
technical writing. Music. Internet music
marketing. Telecommunications. Consumer
advocacy in telecommunications, especially
privacy. M-F relationships. Kinetic sculpture.

Real World Electronics and software for music including:
Interfaces Devil Fish mods for the TB-303, Akai sampler
memory and Csound synthesis software.

===============================================================

dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
Phil Burk
1999-06-17 17:17:35 UTC
Permalink
Larry Troxler wrote:
> I am actually quite surprised that use ksamps>1 results in "***lots***"
> faster efficiency! Is this true for processors with tiny cache only
> (this would make sense - run a tight, small loop in each ugen, which
> will run entirely in cache) , or does it somehow also result in
> improvements for situations where the entire audio chain can be cached?

Most desktop processors have a cache large enough to hold all the unit
code. So I think the speedup from ksamps>1 comes mainly from reducing
the amount of traffic between the cache and the CPU registers, not
between memory and the cache.

At the beginning of the loop, the registers will be loaded with the
parameters and state for that ugen and can then be used multiple times
in the loop. This is certainly true in RISC processors with lots of
registers. In processors derived from the 8080 (ie. the Pentium) there
are very few register so it is harder to reduce the traffic between the
cache and registers.

--
Phil Burk
SoftSynth.com
mailto:***@softsynth.com
http://www.softsynth.com

dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
Luca
1999-06-17 20:56:47 UTC
Permalink
>Larry Troxler wrote:
>> I am actually quite surprised that use ksamps>1 results in "***lots***"
>> faster efficiency! Is this true for processors with tiny cache only
>> (this would make sense - run a tight, small loop in each ugen, which
>> will run entirely in cache) , or does it somehow also result in
>> improvements for situations where the entire audio chain can be cached?
>
>Most desktop processors have a cache large enough to hold all the unit
>code. So I think the speedup from ksamps>1 comes mainly from reducing
>the amount of traffic between the cache and the CPU registers, not
>between memory and the cache.
>
>At the beginning of the loop, the registers will be loaded with the
>parameters and state for that ugen and can then be used multiple times
>in the loop. This is certainly true in RISC processors with lots of
>registers. In processors derived from the 8080 (ie. the Pentium) there
>are very few register so it is harder to reduce the traffic between the
>cache and registers.

Absolutely. The performance equations can be approximated with
straightforward linear ones:

time_per_buffer = overhead + buffer_size * marginal
time_per_sample = time_per_buffer / buffer_size
= overhead/buffer_size + marginal

As Phil Burk said, processors with lots of registers (e.g. RISC, esp.
PowerPC) tend to have low marginal and large overhead, because everything
is loaded into registers for the innermost loop, and because the innermost
function has to save that many more registers and restore them before
returning. Of course, the data points themselves count as 1 additional
save/restore.

In fact, when the chip has lots of registers you can also benefit
enormously from inlining the leaf subroutines, not only because you get rid
of the most-executed overhead layer, but also because of "calling
conventions." On MacOS, roughly half the registers have to be preserved by
the calling routine, half by the callee. So if the either the caller or
callee uses more than half the registers, it has to preserve the others
even though its peer might not actually use them. Then there's the standard
per-function overhead.

All this stuff obviously hits the on-chip cache, but the instruction count
and other semiconductor trivia do matter a lot if you have to do it for
each sample and for each voice. I can witness to 4x performance
improvements in realtime synthesis from optimizations of this sort.

The only cross-platform design that can lead to decent utilization of a
register-intensive CPU while still maintaining the ugen tree at runtime is
the one suggested by Timo Tossavainen. If you can drop the tree, then
dynamically optimizing compilation (as someone else suggested) is even
nicer, since it can flatten out the calling hierarchy to one or a few
layers. Note that cache size is insignificant compared to the effect of the
overhead, unless your data structures are really badly designed, or if in
order to maintain very low realtime latencies you have to yield back to the
OS across miniscule (<32) buffers.

Of course, nothing beats single-layer if your design is simple enough. In
that case, you can also play with tricks that decrease the marginal at the
cost of large increases in overhead.

BTW, AltiVec-enabled PPC chips are just around the corner. If a design can
tolerate a multiple of 4 for ksmps, either through compilation or what have
you, it will run up to 4 times faster by using AltiVec instructions and
registers.

L u c a R a g g i (signature featuring prophylactic latex spaces against
Web spider bites)



dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
Sean Costello
1999-06-17 07:24:28 UTC
Permalink
Robin Whittle wrote:

> Please correct me if I am wrong, but it is my understanding that both
> Music V and cmusic call the code for a unit-generator, and that code
> produces just one sample of audio output. Csound's distinguishing
> characteristic is that it has a variable "ksmps" which tells the unit
> generator how many samples to calculate.

I believe that having a separate control rate was a technique developed by Barry Vercoe for Music
11, and carried into Csound. I guess that any music language that distinguishes between control
signals and audio signals (is SuperCollider this way?) can be viewed as being derivative of Barry
Vercoe's innovations. I think that the Nord Modular also makes this distinction.

BTW, Buchla modular synthesizers also had separate paths for audio and control signals, but for a
different reason - the Buchla synths used optoisolators within their VCAs and VCFs, which had too
slow of a response time to be modulated at audio rates.

I would love to have a provision in Csound, where a separate kr=sr loop could be set up within an
orchestra, for those techniques that require feedback to work. Or can this be done with the zak
ugens?

Sean Costello


dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
Robin Whittle
1999-06-17 07:47:22 UTC
Permalink
Sean Costello wrote, in part:

> I would love to have a provision in Csound, where a separate kr=sr
> loop could be set up within an orchestra, for those techniques that
> require feedback to work. Or can this be done with the zak
> ugens?

If you are keen, you can use some table read and write ugens I wrote
to read ksmps audio samples into a function table, then do whatever
processing you like on them with k-rate code, and then write them out
to an audio variable of ksmps a-rate samples again.

This gets you past the limitations of a-rate ugens, and enables you to
do arbitrarily complex processing on a sample-by-sample basis - as if
ksmps was 1. This would be ideal for chaotic generators, filters and
probably quite a few other things. Intermediate storage from one set
of a-rate samples to the next could be achieved with local k-rate
variables.

Of course it is slow, but it is probably faster to code a small but
crucial part of a piece like this and run the rest at ksmps >= 5 or
so, than run the entire piece at ksmps = 1.

The ugens are: tablera and tablewa

This URL at an old copy of the Csound manual at my web site gives
examples:

http://www.firstpr.com.au/csound/manual/Generate/tablera.html

- Robin

dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
Sean Costello
1999-06-17 07:39:03 UTC
Permalink
Robin Whittle wrote:

> Does anyone have more information about cmusic?

As someone else pointed out, F. Richard Moore's "Elements of Computer Music" is THE place to go for
cmusic info, although I am not sure if cmusic is an active language at this point. It is also pretty
good in describing the internals of computer music languages - it has good descriptions of the
workings of table-lookup oscillators, comb filters, Karplus-Strong, and other cool things, as well
as extensive C code and descriptions of phase vocoding and LPC. However, it skimps on some basic
items; for example, even though it gets into some of the theory of digital filtering, it doesn't
give any useful C code examples for basic building blocks such as reson, or any of the commonly used
digital filters (on the other hand, I did figure out how to code allpass filters from this book).

Going off on a little tangent here, what computer music books have been most useful to people on
this list? As a way of distracting myself from the fact that my car was stolen last night, here is a
list of books that have helped me:

- Computer Music, Charles Dodge and Thomas A. Jerse, both 1st and 2nd editions. The 2nd edition was
the textbook for my computer music classes at the University of Washington, and is excellent in that
role - the sequence followed in introducing concepts is very logical and easy to follow for someone
new to computer music. The 1st edition, from 1985, leaves out the descriptions of more modern
techniques such as phase vocoding, physical modeling, and granular synthesis, but makes up for it
with the inclusion of FORTRAN code for almost all of the "classic" unit generators (based on Music
4BF). The code in Computer Music is much easier to follow than the Csound source code - if you want
to know how one of the older Csound ugens works, having this book around helps a great deal.

- The Technology of Computer Music, by Max V. Mathews et al. A 1969 textbook, that is still
amazingly useful today. No code per se, but excellent in-depth descriptions of the internals of unit
generators that serves as a nice compliment to the code examples in the 1st edition of Dodge &
Jerse.

- Musical Applications of Microprocessors, by Hal Chamberlin. An excellent book that has helped me
bridge the gap between analog synthesis and computer music. Code examples, schematics, in-depth
descriptions that don't require engineering-level math - this book has got it all. Not as useful for
understanding Music N-languages as the previous two books, but very useful for a broad perspective
of the field.

There have been lots of other books that have been useful to me (Foundations of Computer Music,
Representations of Musical Signals, various issues of Electronotes) but the above books have been
the most helpful in the past few months, at least with regards to writing Csound unit generators.
Unfortunately, they are all out of print, but copies turn up on a regular basis - Powell's Technical
Bookstore in Portland, Oregon is a good place to look for this type of stuff.

Sean Costello

P.S. Robin, when is the DevilFish unit generator coming out? :) I'd love to have a digital
simulation of an overdriven diode ladder filter available in Csound, with the output being used to
FM the cutoff...

dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
Robin Whittle
1999-06-17 08:05:48 UTC
Permalink
To add to Sean Costello's list of books, there is an impressive book
on filter design which I have bought but not read yet:

Digital Filter Designer's Handbook
With C++ Algorithms 2nd Edition

C. Britton Rorabaugh

McGraw Hill 1997 ISBN 0-07-053806-9

It comes with a floppy disc of source code. Amazon.com has it for
USD$69.50.

It is a magnificent-looking book, but it assumes more knowledge of
calculus, z-transforms, real and imaginary numbers and the like than I
have at present. It is clear that there is no alternative to knowing
this stuff if you want to do DSP in the frequency domain.

Sean also wrote:

> P.S. Robin, when is the DevilFish unit generator coming out? :)
> I'd love to have a digital simulation of an overdriven diode ladder
> filter available in Csound, with the output being used to
> FM the cutoff...

Life is too short either to:

1 - Write a piece of software which behaves like the Devil Fish
(my modifications to the Roland TB-303).

or

2 - Wait for that software to produce audio.

It is way too complex and idiosyncratic. Its not just a question of
complexity, non-linearities and simulating diodes etc. There are the
matters of needing instant feedback for Filter FM based on the output
of the filter (ksmps = 1!) and of running at much higher sample rates
then 44.1 kHz in order to simulate all the chaotic gyrations which
actually occur - of which we hear the lower frequency components.

Take a look at the waveform which forms the backdrop of the Devil Fish
sound samples page:

http://www.firstpr.com.au/rwi/dfish/sounds/

http://www.firstpr.com.au/rwi/dfish/sounds/df-waveform-q90.jpg

If I get a piece of software kicking and gyrating even vaguely like
the Devil Fish, I will be very proud of myself!

The Devil Fish is complex for a piece of electronics, but it is simple
compared to the reverberation of a room or a guitar sound box. Don't
even think about cymbals, gongs, sitars, sarods or tympanies!

- Robin


===============================================================

Robin Whittle ***@firstpr.com.au http://www.firstpr.com.au
Heidelberg Heights, Melbourne, Australia

First Principles Research and expression: Consulting and
technical writing. Music. Internet music
marketing. Telecommunications. Consumer
advocacy in telecommunications, especially
privacy. M-F relationships. Kinetic sculpture.

Real World Electronics and software for music including:
Interfaces Devil Fish mods for the TB-303, Akai sampler
memory and Csound synthesis software.

===============================================================

dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
James McCartney
1999-06-17 09:00:31 UTC
Permalink
At 1:24 AM -0600 6/17/99, Sean Costello wrote:
>11, and carried into Csound. I guess that any music language that distinguishes between control
>signals and audio signals (is SuperCollider this way?)

yes. However SC allows a separate block size per event.
Control rate signals are always linearly interpolated when consumed
by another ugen so there are never any zipper artifacts. This
adds a bit of overhead, but since it is done in registers in the
ugens loop, it is a small overhead and is much preferred to the
two alternatives: 1) not using control rate but using audio rate.
This causes a lot of overhead because reading from a buffer
of samples is much slower than linearly ramping a value in a register.
2) having zipper noise artifacts.

>can be viewed as being derivative of Barry
>Vercoe's innovations.

Well I stole good ideas from Roger Dannenberg too.
When I read that Nyquist was sample accurate I considered that a raising
of the bar and decided to implement that in SC as well.
It is pretty important when scheduling grains, for example.



--- james mccartney ***@audiosynth.com http://www.audiosynth.com
If you have a PowerMac check out SuperCollider2, a real time synth program:
<ftp://www.audiosynth.com/pub/updates/SC2.1.5.sea.hqx>





dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
Richard Dobson
1999-06-17 09:27:50 UTC
Permalink
A weblink for cmusic and pcmusic is:
http://crca-www.ucsd.edu/cmusic/cmusic.html


I suppose one significant difference between cmusic and Csound, which
might explain the releative lack of 'modern' opcodes in the former, is
that while cmusic has largely remained the property and product of F.R.
Moore, Csound has reaped the benefit of a large, skilful, enthusiastic
and mostly unrestrained net-wide user and development group. This is
partly thanks to the prodigious work of John Fitch just about keeping
everyone and everything co-ordinated, but partly also due to the fact
that it is still essentially standard C, such that anybody can 'have a
go' (including myself), on just about any platform (including the Atari
ST) without have to climb a fierce learning curve of object-orientation,
STL, multi-threading, yacc, lex, et al.



Richard Dobson

Robin Whittle wrote:
>
> Pete Moss pointed out that what I described as my long term plan (a
> framework for C++ to support realtime synthesis) is akin to cmusic.
>
> I think this is true. This post looks at what I understand about
> cmusic and how it only produces a single sample of audio per ugen
> call, compared to Csound which produces ksmps samples, and so can be
> very much faster.
>
> Looking at Dave Philip's marvellous link-farm on software synthesis:
>
> http://www.bright.net/~dlphilp/linux_soundapps.html
>
> leads me to Tim Thompson's venerable PLUM page on music languages,
> which should be at:
>
> http://www.nosuch.com/plum
>
> but this file is absent at present. (I emailed Tim.)
>
> Searching for "cmusic" is tricky, but I found something from 1994 at:
>
> ftp://ccrma-ftp.stanford.edu/pub/cmusic/
>
[etc]

--
Test your DAW with my Soundcard Attrition Page!
http://wkweb5.cableinet.co.uk/rwd (LU: 19th May 1999)
CDP: http://www.bath.ac.uk/~masjpf/CDP/CDP.htm (LU: 6th May 1999)

dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
James McCartney
1999-06-16 20:29:27 UTC
Permalink
At 9:53 AM -0600 6/16/99, Robin Whittle wrote:

>I guess such a patching system can be done in any language - but I
>would much rather write orchestra code than muck around with a GUI on
>that level! Patching instruments together, as Quasimodo does, with
>the GUI interface for each instrument defined it its part of the
>orchestra file . . . . yes I think can be very useful.
>
>
>Personally I think the Csound orchestra and score language should be
>left behind. If I was writing a system from scratch it would not use
>any special language at all - it would be a special framework for
>writing C++ to get on with real-time sound synthesis and all I/O and
>GUI things you might like to hang of that.

Computer music software can be a lot more than just a synth engine
of statically allocated ugens attached to a GUI. This framework is
just too limiting compared to what is possible.
If this is the vision of what is ideal then I think you have not brainstormed
enough about what the real interesting problems are.
There is a lot more I want to "hang on" my DSP engine than a GUI.
Once you get your ideal system how will you attach interesting behaviours
to it? Using C++ to write intelligent players or gesture mappings, or
list processing score manipulation would be very painful.

I think many people do not still grok the kind of things you can do
with a dynamic system like SC or Kyma which is why so many of the same
kind of system keep coming out: GUI+DSP but no brains.
In SC, you can write an algorithmic process to build your patch in real
time, e.g. mapping velocity to how complex a patch you build.
Values in your score can themselves be patches that plug into your
instrument input. For example you could have a note in your score
be a patch of ugens. Then that voice's patch will get built with that
sub-patch plugged into its input instead of just a float value.
Instruments can spawn sub patches recursively to any depth. etc..

That is why I think having a language is important. There is only
so much you can do with a static framework. Static frameworks are not
much better than just having cheap sound hardware. A powerful language
gives you a lot more ability to do what computers can be good at which
is manipulating abstractions. And C++ is just not a very highly abstract
language.


--- james mccartney ***@audiosynth.com http://www.audiosynth.com
If you have a PowerMac check out SuperCollider2, a real time synth program:
<ftp://www.audiosynth.com/pub/updates/SC2.1.5.sea.hqx>





dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
Michael Gogins
1999-06-16 23:03:37 UTC
Permalink
I'm glad to have your response, but let me clear up some misconceptions.

I'm calling for Csound to become an engine built in COMPLETELY
cross-platform, lowest-common-denominator, plain old C. Only runtime library
calls, no system calls. There is an abstract interface for each of (1) MIDI
in, (2) MIDI out, (3) audio in, (4) audio out, (5) plugin function tables,
(6) plugin unit generators, and then (7) VST service for clients, and
finally (8) programmatic control.

All graphical goodies are done in Java and use the abstract interfaces to
get at the kernel. If JavaSound is good enough, all the abstract interfaces
above except (5), (6), (7), and (8) are service provider interfaces for
JavaSound - we don't have to implement the other side of those interfaces at
all.

Threading issues can be dealt with by ignoring them, for the most part; the
Java host can spawn a new thread to render a Csound job, but the engine need
only be single-threaded as it now is.

I would repeat my rant as something to do for SAOL - if an efficient
complete implementation existed. Csound exists, and it's DEEP.


-----Original Message-----
From: rdbr03035 <***@cableinet.co.uk>
Cc: music-dsp <music-***@shoko.calarts.edu>; CSOUND <***@maths.ex.ac.uk>
Date: Wednesday, June 16, 1999 10:32 AM
Subject: Re: Csound and other synthesis systems


>I agree that, taken direfctly in the conext of newer softsynths, Csound
>can look 'creaky', and it is indeed a tempting thought to revamp the
>whole thing to exploit the best of modern GUI/Plugin techniques. I have
>long thought about doing this myself 'as an exercise'. However, one
>vital aspect of Csound it it's extremely wide cross-platform character;
>and indeed it's core functionality as a console program has advantages
>for visually-impaired users.
>
>I don't think this could be done piece-meal. Basically, one would have
>to take the score and orc syntax and create a new engine from scratch,
>with multiple thread, dynamic libraries, and all the superstructure of a
>modern GUI-based application.
>
>Set against this is SAOL, which is ~fully~ public domain, and which is
>open for adaptation in any number of ways, has a more up-to-date
>language, and even has a means of compiling into a stand-alone
>application, thanks to 'cfront'. The legacy of SAOL scores is also
>arguably less significant, so compatibility at the command-line level is
>scarcely an issue. After all, SAOL is expected to be embedded in set-top
>boxes ere long!
>
>In the end, it depends how stronly the moral imperative that Csound
>~should~ be at the 'leading edge' as a functioning softsynth, in the
>terms described. As it stands, it is a treasure-trove of dsp ideas, of
>unique educational value, a feature that I value highly. The issue then
>is one of modernity v fragmentation (unless it can be done exclusively
>using Java and/or TCL/TK), an issue which simply does not arise for
>SAOL. Csound ~is~ it's source code, but that is not strictly true of
>SAOL - 'saolc' is merely an example implementation.
>
>If we treat the score and orc syntax similarly, as a specification (as
>we can reasonably do), there is no reason why some new program cannot be
>written which implements it in a more modern form. The sticking point is
>then the title (in the legal sense), as my understanding is that
>ultimately this still belongs to MIT and Barry Vercoe.
>
>
>Richard Dobson
>
>
>Michel Jullian wrote:
>>
>> Michael Gogins wrote:
>> <cut>
>> > Csound could be put firmly back at the leading edge of the state of the
art
>> > if:
>> >
>> > Csound gets plugin unit generators and function tables with a SIMPLE, I
mean
>> > REALLY simple, API.
>> > Csound gets double-precision signal processing (Buzz and Generator use
>> > floats).
>> > Csound gets low-latency MIDI and audio input and output that works more
or
>> > less the same on its major platforms.
>> > Csound gets an at least semi-snazzy GUI including unit generator
wiring.
>> > Csound gets an external API for programmatic control.
>> > Csound can act as a VST plugin.
>>
>> This last point is _very_ good idea (the other points too). The VST 2
sdk,
>> featuring full midi control of plugin synths (AFAIK it's the only plugin
>> architecture with this feature) and a multiplatform GUI API, is due out
any
>> day now (watch out for it on steinberg's vst devs list
>> <vst-***@steinberg.net>). Furthermore it is open not only to plugin
>> developers but also to host developers, which should help it become a
standard.
>>
>> What would be really nice would be if csound could "compile" orcs as vst
>> plugins, somehow, instead of (or as well as) acting as a vst plugin.
>>
>> --
>> Greetings,
>> Michel
>> .........................................................................
>> Michel Jullian Directeur General email ***@exbang.com
>> Exbang Industries S.A.
>> Mas Chauvain route de Villeneuve tel +33(0) 499 529 878
>> Maurin 34970 Lattes France fax +33(0) 499 529 879
>> .........................................................................


dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
Michael Gogins
1999-06-16 23:10:23 UTC
Permalink
I'm afraid you missed one major thrust of my message. I am in fact quite
concerned about multi-platform capability. My system Silence runs on both
Windows and Linux (thanks to Dave Pnillips). If Csound is a "pure ANSI C
runtime library" engine and implements Java native methods, and the Csound
GUI and extras are all done in Java, then the whole system is cross-platform
without much, if indeed any, extra work at all.

-----Original Message-----
From: Robin Whittle <***@firstpr.com.au>
To: music-***@shoko.calarts.edu <music-***@shoko.calarts.edu>
Cc: CSOUND <***@maths.ex.ac.uk>
Date: Wednesday, June 16, 1999 12:01 PM
Subject: Re: Csound and other synthesis systems


>Michael Gogins mounted his soapbox on the limitations of Csound. He
>seemed to be focused on a Windows-based patchable-synthesiser view of
>software synthesis.
>
>Here's the view from my particular soapbox.
>
>There is much more to software synthesis and Csound than being like a
>Moog modular on MIDI, but such a thing would certainly be a marvel and
>would be widely used, including by me!
>
>There are those of us who do not want to run things on Windows if we
>can help it. (I find Windows a seriously unreliable and frustrating
>operating system, despite its creature comforts which I know and
>love. I have no interest in owning a Mac - too expensive and weird.)
>We want open-source free software which runs on an open-source
>operating system - most obviously Linux. We want all the compilers
>etc. to be open-source too.
>



dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
Michael Gogins
1999-06-16 23:12:00 UTC
Permalink
Correct me if I'm wrong - but doesn't cmusic have many fewer unit generators
than Csound and no real-time MIDI input or audio output?

-----Original Message-----
From: pete moss <***@bigfoot.com>
To: Robin Whittle <***@firstpr.com.au>
Cc: music-***@shoko.calarts.edu <music-***@shoko.calarts.edu>; CSOUND
<***@maths.ex.ac.uk>
Date: Wednesday, June 16, 1999 1:54 PM
Subject: Re: Csound and other synthesis systems


>isnt that what cmusic does? except with c, (no ++).
>
>:P
>
>
>Robin Whittle wrote:
>> Personally I think the Csound orchestra and score language should be
>> left behind. If I was writing a system from scratch it would not use
>> any special language at all - it would be a special framework for
>> writing C++ to get on with real-time sound synthesis and all I/O and
>> GUI things you might like to hang of that. It would do non-real-time
>> work as well, and the same principles would probably apply to
>> generating video images too. The C++ core elements would interface to
>> things in other languages, for instance novel score languages or
>> whatever you liked to create.


dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
pete moss
1999-06-17 01:44:41 UTC
Permalink
i dont know. aal i do know is that it offers the framework similar to
what robin was saying. i have never actually used it, cause i got
csound!

:P


Michael Gogins wrote:
>
> Correct me if I'm wrong - but doesn't cmusic have many fewer unit generators
> than Csound and no real-time MIDI input or audio output?
>
> -----Original Message-----
> From: pete moss <***@bigfoot.com>
> To: Robin Whittle <***@firstpr.com.au>
> Cc: music-***@shoko.calarts.edu <music-***@shoko.calarts.edu>; CSOUND
> <***@maths.ex.ac.uk>
> Date: Wednesday, June 16, 1999 1:54 PM
> Subject: Re: Csound and other synthesis systems
>
> >isnt that what cmusic does? except with c, (no ++).
> >
> >:P
> >
> >
> >Robin Whittle wrote:
> >> Personally I think the Csound orchestra and score language should be
> >> left behind. If I was writing a system from scratch it would not use
> >> any special language at all - it would be a special framework for
> >> writing C++ to get on with real-time sound synthesis and all I/O and
> >> GUI things you might like to hang of that. It would do non-real-time
> >> work as well, and the same principles would probably apply to
> >> generating video images too. The C++ core elements would interface to
> >> things in other languages, for instance novel score languages or
> >> whatever you liked to create.
>
> dupswapdrop: the music-dsp mailing list and website
> http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html

dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
Michael Gogins
1999-06-16 23:19:38 UTC
Permalink
Thanks for your response to this discussion. I remember your exhibition of
SuperCollider at the last ICMC and was quite impressed.

I would love if it SuperCollider:

(a) ran on Windows
(b) had plugin unit generators (or words in its language - is that even
possible?)
(c) had an external API
(d) ran on Windows

-----Original Message-----
From: James McCartney <***@io.com>
To: music-***@shoko.calarts.edu <music-***@shoko.calarts.edu>
Cc: CSOUND <***@maths.ex.ac.uk>
Date: Wednesday, June 16, 1999 3:56 PM
Subject: Re: Csound and other synthesis systems


>At 9:53 AM -0600 6/16/99, Robin Whittle wrote:
>
>>I guess such a patching system can be done in any language - but I
>>would much rather write orchestra code than muck around with a GUI on
>>that level! Patching instruments together, as Quasimodo does, with
>>the GUI interface for each instrument defined it its part of the
>>orchestra file . . . . yes I think can be very useful.
>>
>>
>>Personally I think the Csound orchestra and score language should be
>>left behind. If I was writing a system from scratch it would not use
>>any special language at all - it would be a special framework for
>>writing C++ to get on with real-time sound synthesis and all I/O and
>>GUI things you might like to hang of that.
>
>Computer music software can be a lot more than just a synth engine
>of statically allocated ugens attached to a GUI. This framework is
>just too limiting compared to what is possible.
>If this is the vision of what is ideal then I think you have not
brainstormed
>enough about what the real interesting problems are.
>There is a lot more I want to "hang on" my DSP engine than a GUI.
>Once you get your ideal system how will you attach interesting behaviours
>to it? Using C++ to write intelligent players or gesture mappings, or
>list processing score manipulation would be very painful.
>
>I think many people do not still grok the kind of things you can do
>with a dynamic system like SC or Kyma which is why so many of the same
>kind of system keep coming out: GUI+DSP but no brains.
>In SC, you can write an algorithmic process to build your patch in real
>time, e.g. mapping velocity to how complex a patch you build.
>Values in your score can themselves be patches that plug into your
>instrument input. For example you could have a note in your score
>be a patch of ugens. Then that voice's patch will get built with that
>sub-patch plugged into its input instead of just a float value.
>Instruments can spawn sub patches recursively to any depth. etc..
>
>That is why I think having a language is important. There is only
>so much you can do with a static framework. Static frameworks are not
>much better than just having cheap sound hardware. A powerful language
>gives you a lot more ability to do what computers can be good at which
>is manipulating abstractions. And C++ is just not a very highly abstract
>language.
>
>
> --- james mccartney ***@audiosynth.com http://www.audiosynth.com
>If you have a PowerMac check out SuperCollider2, a real time synth program:
><ftp://www.audiosynth.com/pub/updates/SC2.1.5.sea.hqx>
>
>
>
>
>
>dupswapdrop: the music-dsp mailing list and website
>http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
>


dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
Sean Costello
1999-06-17 04:32:11 UTC
Permalink
Michael Gogins wrote:

> I would love if it SuperCollider:
>
> (a) ran on Windows
> (b) had plugin unit generators (or words in its language - is that even
> possible?)
> (c) had an external API
> (d) ran on Windows

I would like to put my vote in for Linux, or BeOS, or anything that runs on an Intel-type processor.
I will buy BeOS in a second, just to run SuperCollider. I have seen SuperCollider demoed, and am
very impressed. I would also like to have the capability of creating unit generators or the
equivalent (I've just completed some nice Csound ugens, and would love to use them in the
SuperCollider environment).

Sean Costello

dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
Michael Gogins
1999-06-17 01:51:31 UTC
Permalink
I would seriously consider (at this point I feel I would be quite eager) to
collaborate with you on a port of SuperCollider -- not to Linux
specifically, but to Java. In other words, the SuperCollider virtual machine
would be implement native methods in a Java class. If JavaSound proves
usable, then porting to Java would be porting to Windows and Solaris for
certain, to Linux almost certainly, and probably to the Mac as well.

Other objectives:

Open Source (not a fixed unalterable requirement)

Plugin unit generators and language primitives with some rather extensive
consultation and discussion and comparison of existing designs (Csound,
Buzz, VST round two, DirectShow)

Is there any way that the SuperCollider language would lend itself to
implementation of those so-popular unit generator wiring forms? Now that I
have played with Generator a little, I rather like them.


-----Original Message-----
From: James McCartney <***@io.com>
To: music-***@shoko.calarts.edu <music-***@shoko.calarts.edu>; CSOUND
<***@maths.ex.ac.uk>
Date: Wednesday, June 16, 1999 7:00 PM
Subject: Re: Csound and other synthesis systems


>At 6:26 AM -0600 6/16/99, Michael Gogins wrote:
>
>>Other
>>programs of note that I don't talk about here are SuperCollider and
>>GrainWave.
>
>OK, but...
>
>>What is needed here is a reasonable compromise between the power and
>>amenability for experimentation of a bare-bones piece of academic UNIX
>>software, and a user-friendly GUI and user-extensible plugin architecture,
>>with realtime performance AND non-realtime soundfile rendering. This is
the
>>wonderful musical instrument that is evolving before our very eyes (and
>>ears), and Csound already contains all the necessary guts for the thing.
>
>If expressive power is what you want then why go with Csound?
>
>Csound : assembly language :: SuperCollider : Smalltalk
>
>(OK this is crossposted to the Csound list so I can see those
>flames rolling in.. 8-0 )
>
>Seriously, I would be interested in any serious proposals for
>collaboration on a port of SuperCollider to Linux.
>I think a SuperCollider + GTK on Linux would be very cool.
>
>SuperCollider was written from the beginning to be used in real time.
>All operations were conceived and written with that in mind. For example
>variable delay lines of any maximum length can be allocated and used
>immediately without needing to be zeroed out first. (SC can do non
>real time just fine too.)
>
>Right now SC is closed source, however I have been considering
>opening the source to the language virtual machine.
>Plugins of UGens and language primitives are both possible.
>SC was designed for easy plugging in of language primitives.
>The virtual machine should be easily portable, there is no
>Mac specific code in there.
>
>--
>
>SuperCollider is a dynamically typed, real time garbage collected,
>fully object oriented language like Smalltalk with support for true
closures,
>coroutines, positional or keyword arguments, variable length argument
>lists, default argument values, etc.
>It has a class library of 341 classes including a full set
>of Collection classes like Dictionary, Set, SortedList, etc.
>There are currently over 200 unit generators.
>
>--
>
>
> --- james mccartney ***@audiosynth.com http://www.audiosynth.com
>If you have a PowerMac check out SuperCollider2, a real time synth program:
><ftp://www.audiosynth.com/pub/updates/SC2.1.5.sea.hqx>
>
>
>
>
>
>dupswapdrop: the music-dsp mailing list and website
>http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
>


dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
Paul Barton-Davis
1999-06-17 02:20:57 UTC
Permalink
James McCartney writes:

>SuperCollider is a dynamically typed, real time garbage collected,
>fully object oriented language like Smalltalk with support for true closures,
>coroutines, positional or keyword arguments, variable length argument
>lists, default argument values, etc.
>It has a class library of 341 classes including a full set
>of Collection classes like Dictionary, Set, SortedList, etc.
>There are currently over 200 unit generators.

While I share your conviction neither Csound nor C++ are the right
language to write complex algorithmic processes/patches/whatever, that
doesn't mean that I think that the same language should be used for
both those complex algorithmic processes and the specification of what
is essentially a DSP program.

There is no justification for a DSP program to contain concepts such
as a Dictionary or a SortedList; on the other hand, there is no
justification for a sophisticated algorithmic language to be
constrained by the execution model embodied in a DSP program.

Furthermore, I don't want to have to be stuck with only a single
language to program a DSP with - Csound is bad enough, and I don't
believe that any other language is perfect for this. What's really
important is not the visible language but the inner parse tree that is
used to represent DSP programs written in any language. Quasimodo has
the basic structure to support multiple DSP languages by compiling
them all down to the same internal form, and these different languages
are themselves intended to be "plugins".

But to return to my point: I don't *want* a dynamically typed, real
time garbage collected, fully object oriented language to write DSP
code in. I *do* want such a language to write higher level
abstractions in, and possibly to have it automatically generate DSP
code.
Timo Tossavainen
1970-01-01 00:00:00 UTC
Permalink
On Thu, 17 Jun 1999, Robin Whittle wrote:

> I agree with what Larry Troxler wrote about how important it is for
> ksmps to be 1 in some applications - particularly those involving
> audio feedback.
>
> Ideally a system would enable some parts to be executed with various
> ksmps rates. It is a tall order, and the sort of thing I am
> contemplating for "Topsy" which is pure vapour-ware at present and
> likely to remain so for several years at least.

This not actually very hard to do. Just solve the strongly connected
components of the signal flow network and at same time you get the order
of the update from the first DFS. You can use any ksmps in UG which form a
component by themselves and ksmps = 1 in components that have more UGs. In
code you have to handle the connections between the components as special
cases (ie. fill output vectors from the outputs from the components and
feed single input samples to the inputs leading to the component).
Doing this while the user dynamically alters the connections isn't
that easy. Possible ? probably.

Wouldn't it be best to implement a compiler, that compiles the UG
network to a single monolithic piece of code and then gets rid of the
function calls and unnecessary memory accesses, that are making the synth
slower at kr = sr. In that there would still be some use for using vectors
of data to keep the most of the data needed in calculations (for example,
filter coefficients) in registers. For instance have it generate C and
turn it into something like a DLL and then use that. Of course it would be
a lot easier in Lisp, since you can generate and compile code in memory
and don't need to invoke the compiler in a shell.

Timo


dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
James McCartney
1999-06-17 06:12:18 UTC
Permalink
At 8:20 PM -0600 6/16/99, Paul Barton-Davis wrote:

>There is no justification for a DSP program to contain concepts such
>as a Dictionary or a SortedList; on the other hand, there is no
>justification for a sophisticated algorithmic language to be
>constrained by the execution model embodied in a DSP program.

Just because you cannot justify it to yourself does not mean
that there are no justifiable uses. And the algorithmic language
is in no way constrained or vice versa. In fact you have much
greater flexibility because your algorithmic composition can get
down and mess with the building structure of your DSP algorithms.
I do this a lot. It is very powerful. Maybe you need to use your
imagination a bit more.

>But to return to my point: I don't *want* a dynamically typed, real
>time garbage collected, fully object oriented language to write DSP
>code in.

The SC language does not implement the UGens, it creates the patching
structure. Again I think that because you have never used it
or been exposed to what you can do, you do not realize the power there.

>
James McCartney
1999-06-17 07:15:27 UTC
Permalink
At 11:42 PM -0600 6/16/99, Tobias Kunze wrote:
>Hi James-
>
>I've always wondered how on earth you came up with the name
>"SuperCollider" from. Could you explain? Graned, it's trivia,
>but there has been so much serious discussion going on recently,
>I think we could use a bit of enchantment :)
>
>And while I'm at the mic: damn straight, most people are so
>glued to their unit-generator-music-5 worldview, they simply
>can't imagine the possibilities of a runtime variable signal
>flow.

The SuperConducting SuperCollider was a Texas Big Science
project that was feeding lots of the physicists working below me
while I worked at the Astronomy Dept at Univ of Texas at Austin.
Its funding got killed by Congress.
Meanwhile I had these two pieces of code, one a synth language called
Synth-O-Matic that I wrote in 1990, and a MAX object called Pyrite
that was a real time GCed dynamic language, i.e. a "number cruncher"
program and a (lisp) "atom smasher" program. I was going to "collide" these
two programs together to see if a dynamic language could run a synth
engine in real time. I was sure it was going to fail so I named it after
the supercollider.
I had not intended to keep that name but it stuck. Sometime during
that period OSC had a contract to publish it. That fell through when
they got bought by MacroMedia. Some folks hated the name so much that
I decided I should call my next project something that no one would
feel comfortable saying in public. So far the winner is "diarrhea popsicle".
That will be the name of my next synth program, so hope that "SuperCollider"
lasts a long time.. ;-}


--- james mccartney ***@audiosynth.com http://www.audiosynth.com
If you have a PowerMac check out SuperCollider2, a real time synth program:
<ftp://www.audiosynth.com/pub/updates/SC2.1.5.sea.hqx>





dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
James McCartney
1999-06-17 06:18:09 UTC
Permalink
At 5:19 PM -0600 6/16/99, Michael Gogins wrote:
>Thanks for your response to this discussion. I remember your exhibition of
>SuperCollider at the last ICMC and was quite impressed.
>
>I would love if it SuperCollider:
>
>(a) ran on Windows
>(b) had plugin unit generators (or words in its language - is that even
>possible?)
>(c) had an external API
>(d) ran on Windows

b & c are planned and are more an issue of documentation than
implementation.

a & d are more religious things I guess. I am of the opinion recently
that OS's are too important to be proprietary. I am on the Mac nowadays
mostly due to historical inertia and the fact that I like the PowerPC
chip. At one time the Mac had provable UI advantages, but those are
becoming harder to justify and as an OS it is really impossible to justify.
Perhaps MacOSX will make the Mac more able to be compatible with the rest
of the posix world, but I've heard that most posix things are not a
simple recompile on MacOSX.

BeOS has some nice real time media facilities available so I like that
too though it definitely has its own problems.

I find no reason to like Windows other than market size and
that is not the reason I'm doing this. Win has all the same problems
as MacOS does and the UI is not as consistent.
If I'm on an Intel machine I'd much rather be running Linux or BeOS.


--- james mccartney ***@audiosynth.com http://www.audiosynth.com
If you have a PowerMac check out SuperCollider2, a real time synth program:
<ftp://www.audiosynth.com/pub/updates/SC2.1.5.sea.hqx>





dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
Michael Gogins
1999-06-17 05:52:48 UTC
Permalink
Whatever your religious objections to Windows, if you create a
cross-platform virtual machine that works with Java, then you get it to run
on Linux (or BeOS if BeOS have a Java virtual machine) and, without hurting
anyone on those other platforms, it also runs on Windows where there are
lots and lots of musicians who could use SuperCollider.

I started on Unix and moved to Windows not for religious reasons, but
because it made my musical life happen at home and more cheaply than any
other way without really losing any vital functionality.

I personally believe that some virtual-machine system is bound to run almost
all software in the end. I think Java, its descendent, or something like it
will end up running on everything from supercomputers to watches. I think
this will happen because software is more expensive than hardware and
general-purpose software is cheaper than special-purpose software. Note how
the Ptolemy DSP project at UCB for the Navy has moved from C++ to Java in
the past two years. Also Roldan Pozo and other big guns in numerics and
supercomputing are pushing Java Grande because, I suspect, they anticipate
distributed Java apps that can do more than any single app on any single
machine.

-----Original Message-----
From: James McCartney <***@io.com>
To: music-***@shoko.calarts.edu <music-***@shoko.calarts.edu>
Cc: CSOUND <***@maths.ex.ac.uk>
Date: Thursday, June 17, 1999 1:17 AM
Subject: Re: Csound and other synthesis systems


>At 5:19 PM -0600 6/16/99, Michael Gogins wrote:
>>Thanks for your response to this discussion. I remember your exhibition of
>>SuperCollider at the last ICMC and was quite impressed.
>>
>>I would love if it SuperCollider:
>>
>>(a) ran on Windows
>>(b) had plugin unit generators (or words in its language - is that even
>>possible?)
>>(c) had an external API
>>(d) ran on Windows
>
>b & c are planned and are more an issue of documentation than
>implementation.
>
>a & d are more religious things I guess. I am of the opinion recently
>that OS's are too important to be proprietary. I am on the Mac nowadays
>mostly due to historical inertia and the fact that I like the PowerPC
>chip. At one time the Mac had provable UI advantages, but those are
>becoming harder to justify and as an OS it is really impossible to justify.
>Perhaps MacOSX will make the Mac more able to be compatible with the rest
>of the posix world, but I've heard that most posix things are not a
>simple recompile on MacOSX.
>
>BeOS has some nice real time media facilities available so I like that
>too though it definitely has its own problems.
>
>I find no reason to like Windows other than market size and
>that is not the reason I'm doing this. Win has all the same problems
>as MacOS does and the UI is not as consistent.
>If I'm on an Intel machine I'd much rather be running Linux or BeOS.
>
>
> --- james mccartney ***@audiosynth.com http://www.audiosynth.com
>If you have a PowerMac check out SuperCollider2, a real time synth program:
><ftp://www.audiosynth.com/pub/updates/SC2.1.5.sea.hqx>
>
>
>
>


dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
James McCartney
1999-06-17 07:08:00 UTC
Permalink
At 11:52 PM -0600 6/16/99, Michael Gogins wrote:
>Whatever your religious objections to Windows, if you create a
>cross-platform virtual machine that works with Java, then you get it to run
>on Linux (or BeOS if BeOS have a Java virtual machine) and, without hurting
>anyone on those other platforms, it also runs on Windows where there are
>lots and lots of musicians who could use SuperCollider.

Java's GC is not real time. Java is not a real time language.
Java cannot run at interrupt level in a sound card's callback routine.


--- james mccartney ***@audiosynth.com http://www.audiosynth.com
If you have a PowerMac check out SuperCollider2, a real time synth program:
<ftp://www.audiosynth.com/pub/updates/SC2.1.5.sea.hqx>





dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
j***@maths.bath.ac.uk
1999-06-17 11:58:41 UTC
Permalink
Message written at 16 Jun 1999 22:54:42 +0100

OK, so someone has to display their ignorance. What is a VST plugin?
What does it do for me?

==John ffitch

dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
Michel Jullian
1999-06-17 16:54:49 UTC
Permalink
***@maths.bath.ac.uk wrote:

> OK, so someone has to display their ignorance. What is a VST plugin?
> What does it do for me?

Basically, Steinberg's VST (Virtual Studio Technology) is a well-documented
(sample code provided for plugins _and_ for hosts), multiplatform (VST1 sdks
are available for Mac, Windows and SGI), dsp plugin architecture for
sequencers and other audio apps.

It used to be open at the plugin end only, but it's now open at the other end
too. So that not only Cubase, but also Logic, StudioVision, and others,
including a new kind of audio application we are currently developing at
Exbang (top secret, won't tell you more ;-), host VST plugins. Its openness
at the host end makes this architecture much more attractive for developers
who don't necessarily want to limit the scope of their creations to Steinberg products.

In its current version (1.0) it only allows for audio effects and non-MIDI
parameter passing. Upcoming version 2.0 (any day now) allows for both audio
effects and synths, and passes MIDI events (sample accurate, I believe)
through the plugin interface. VST2 also provides a cross-platform GUI API for
faders etc so that you can concentrate on real work (dsp) instead of dealing
with platform-specific GUI issues.

I have no personal interest whatsoever in promoting Steinberg, but VST
apparently can be used freely, and I think it is the best way to go for people
who want their dsp code, whether free or commercial, to be widely and
efficiently used for making "real" music (I mean with professional-grade sequencers).

For more information cf my other mails in this thread and see :
http://www.steinberg.net/developers/VSTPlugInsDocumentation/index.html
(still version 1.0)

Oh, and congratulations for the great job you're doing with csound.
--
Greetings,
Michel
.........................................................................
Michel Jullian Directeur General email ***@exbang.com
Exbang Industries S.A.
Mas Chauvain route de Villeneuve tel +33(0) 499 529 878
Maurin 34970 Lattes France fax +33(0) 499 529 879
.........................................................................


dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
Michel Jullian
1999-06-17 14:29:30 UTC
Permalink
Michael Gogins wrote:
>
> Another misconception: these days, Java IS fast. I do all my new DSP coding
> in Java. Java with best compilers is now about 1/2 the speed of C++. This is
> fast enough.

Don't you think a factor of 2 is a lot ? Pity to waste half of your cpu power
for the beauty of no recompile. Non-platform specific C or C++ code might be
just as well.
--
Greetings,
Michel
.........................................................................
Michel Jullian Directeur General email ***@exbang.com
Exbang Industries S.A.
Mas Chauvain route de Villeneuve tel +33(0) 499 529 878
Maurin 34970 Lattes France fax +33(0) 499 529 879
.........................................................................



dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
Paul Schreiber
1999-06-17 12:49:48 UTC
Permalink
VST is a editing/sequencer progran for Mac and PC from a company called
Steinberg/Jones. Very popular in USA.

Paul Schreiber
Synthesis Technology
www.synthtech.com/motm <<<analog modular synthesizers


-----Original Message-----
From: ***@maths.bath.ac.uk <***@maths.bath.ac.uk>
To: music-***@shoko.calarts.edu <music-***@shoko.calarts.edu>;
***@maths.ex.ac.uk <***@maths.ex.ac.uk>
Date: Thursday, June 17, 1999 7:30 AM
Subject: Re: Csound and other synthesis systems


>Message written at 16 Jun 1999 22:54:42 +0100
>
>OK, so someone has to display their ignorance. What is a VST plugin?
>What does it do for me?
>
>==John ffitch
>
>dupswapdrop: the music-dsp mailing list and website
>http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
>
>


dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
James McCartney
1999-06-17 15:32:24 UTC
Permalink
>Michael Gogins wrote:
>>
>> Another misconception: these days, Java IS fast. I do all my new DSP coding
>> in Java. Java with best compilers is now about 1/2 the speed of C++. This is
>> fast enough.

Well I did not receive the above posting, so I may be quoting out of context.

First, half as fast is too slow when I've spent lots of time
just to get 20% speed ups in C.

Second, whether something is fast has nothing to do with whether
something is real time. A real time system has guarantees on latency.
Java's GC scheme does not. It must suspend all threads to do its collection
and the way its finalization scheme is designed it is difficult to
make it a guaranteed real time system. You can't guarantee that on
any particular system you'll be able to get a real time GC for your
Java implentation.

I know of no Java that is capable of running in real time with performance
guarantees and able to run in an interrupt routine where memory allocation
is illegal.
SuperCollider was designed to be able to do this.

Third, the SC virtual machine is C which is far more portable than Java.
If I wanted to port to a DSP chip I could not get a Java compiler for it.
That is why SC is in C and not C++.


This is from a different posting:

>Is there any way that the SuperCollider language would lend itself to
>implementation of those so-popular unit generator wiring forms? Now that I
>have played with Generator a little, I rather like them.

Yes, however wire up diagrams are not easily able to express the
dynamic things you can do in a supercollider program.
It would be a subset of what you could do with the language.


--- james mccartney ***@audiosynth.com http://www.audiosynth.com
If you have a PowerMac check out SuperCollider2, a real time synth program:
<ftp://www.audiosynth.com/pub/updates/SC2.1.5.sea.hqx>





dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
James McCartney
1999-06-17 20:38:02 UTC
Permalink
At 1:12 PM -0600 6/17/99, Paul Barton-Davis wrote:

>using in a multiprocessor system. If you wanted to do this kind thing
>on Linux, BeOS or various other systems, you'd be totally hosed. You
>would totally destroy system timing, amongst other things.

Totally false. How would I totally destroy system timing?
I see no problem at all with porting to Linux or BeOS.
I'm writing BeOS MediaKit code right now. I am aware of the issues
involved there and there is nothing there that would prevent SC
from living there.

You could
>never do inter-processor synchronization within an interrupt routine.

On the Mac it is an interrupt routine, on BeOS you are in a MediaKit
call back where you are also not able to do things which take
unbounded amounts of time either. SC's GC runs in bounded time.
Java's does not.

>I think you will find that GCC exists for most of the worthwhile DSP
>chips out there, and with it, G++. Thats certainly true for the SHARC 26XXX
>and Motorola 56K series.

Availability of C++ compilers are improving but they are still horrible
for the most part for DSP code generation.
I wrote the high level firmware for the Level Control Systems digital
mixers http://www.lcsaudio.com and we used C because the C++ compilers
sucked so badly.

I also wrote LCS's host software on BeOS. It is still one of the
largest programs ever shipped on BeOS, so I think I know that platform.


--- james mccartney ***@audiosynth.com http://www.audiosynth.com
If you have a PowerMac check out SuperCollider2, a real time synth program:
<ftp://www.audiosynth.com/pub/updates/SC2.1.5.sea.hqx>





dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
Paul Barton-Davis
1999-06-17 19:12:59 UTC
Permalink
>I know of no Java that is capable of running in real time with performance
>guarantees and able to run in an interrupt routine where memory allocation
>is illegal. SuperCollider was designed to be able to do this.

i am not sure how much of SC runs (or can run) in an interrupt
routine, but if its a lot then i am suprised that you seem proud of
this. although this is undoubtedly an approach that helps raw speed,
it seems incredibly unportable, and also very hard to ever plan on
using in a multiprocessor system. If you wanted to do this kind thing
on Linux, BeOS or various other systems, you'd be totally hosed. You
would totally destroy system timing, amongst other things. You could
never do inter-processor synchronization within an interrupt routine.

i am at a loss to understand why you chose to do things in an
interrupt routine. i guess i am just too much of a unix head to grok
the Mac (and maybe Windows) world.

>Third, the SC virtual machine is C which is far more portable than Java.

Michael's idea, I think, is to not write the VM in Java, but to use a
C implementation to support Java's "native methods" (i.e. things that
appear to be builtins in Java). I'm not attracted to this idea all
that much, but it seems like quite a reasonable one to me.

>If I wanted to port to a DSP chip I could not get a Java compiler for it.
>That is why SC is in C and not C++.

I think you will find that GCC exists for most of the worthwhile DSP
chips out there, and with it, G++. Thats certainly true for the SHARC 26XXX
and Motorola 56K series.

--p

dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
Michael Gogins
1999-06-17 22:39:10 UTC
Permalink
I enthusiastically second the notion of simplicity in something like Csound.
I think something similar will evolve in Java with a modest GUI.

-----Original Message-----
From: Richard Dobson <***@cableinet.co.uk>
To: Robin Whittle <***@firstpr.com.au>
Cc: pete moss <***@bigfoot.com>; music-***@shoko.calarts.edu
<music-***@shoko.calarts.edu>; CSOUND <***@maths.ex.ac.uk>
Date: Thursday, June 17, 1999 5:25 AM
Subject: Re: cmusic Was: Csound and other synthesis systems


>A weblink for cmusic and pcmusic is:
>http://crca-www.ucsd.edu/cmusic/cmusic.html
>
>
>I suppose one significant difference between cmusic and Csound, which
>might explain the releative lack of 'modern' opcodes in the former, is
>that while cmusic has largely remained the property and product of F.R.
>Moore, Csound has reaped the benefit of a large, skilful, enthusiastic
>and mostly unrestrained net-wide user and development group. This is
>partly thanks to the prodigious work of John Fitch just about keeping
>everyone and everything co-ordinated, but partly also due to the fact
>that it is still essentially standard C, such that anybody can 'have a
>go' (including myself), on just about any platform (including the Atari
>ST) without have to climb a fierce learning curve of object-orientation,
>STL, multi-threading, yacc, lex, et al.



dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
Michael Gogins
1999-06-17 23:02:04 UTC
Permalink
VST is a plugin specification originated by Steinberg. People write code for
compressing vocal tracks, applying EQ, pitch shifting, de-noising, and the
like. These are then loaded at runtime by Cubase VST, a digital audio MIDI
sequencer, which can use them to process audio tracks that it records. Other
manufacturers have adopted the specification because it is a plain vanilla C
interface (yay!) unlike the DirectShow plugins also widely used for the same
purpose.

Steinberg has announced a VST 2 specification that will enable plugins to
access the MIDI events coming into the sequencer. This would make it
possible to create a VST plugin version of Csound that would act as a
software synthesizer and/or effects processor in the context of Cubase. But
the VST specification is not yet available. When it does become available I
will take a close look at it and I probably will give AXCsound a VST plugin
interface at that time.

-----Original Message-----
From: ***@maths.bath.ac.uk <***@maths.bath.ac.uk>
To: music-***@shoko.calarts.edu <music-***@shoko.calarts.edu>;
***@maths.ex.ac.uk <***@maths.ex.ac.uk>
Date: Thursday, June 17, 1999 8:01 AM
Subject: Re: Csound and other synthesis systems


>Message written at 16 Jun 1999 22:54:42 +0100
>
>OK, so someone has to display their ignorance. What is a VST plugin?
>What does it do for me?
>
>==John ffitch


dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
Michael Gogins
1999-06-17 23:06:39 UTC
Permalink
I just wrote a program that uses recurrent iterated function systems to
generate fractals, displaying them in a finished GUI, then translating them
directly into WAV soundfiles using linearly interpolated oscillator bank
additive synthesis. This program saves and loads parameter files also. The
entire program took me 3 days to write. I did a similar program in C++
several years ago (I demonstrated it at an ICMC); it took me weeks to write
and did not run a whole lot faster, it had more bugs, and it was not as
finished. The difference in ease of writing is not due only to my increased
experience and having a prototype of the program. I have had similar
experience with other programs, some of which I wrote in Java first and then
in C++ rather than the reverse as in this case.

I think I have enough hands-on experience with both languages to see which
is actually better for this kind of purpose.

-----Original Message-----
From: Michel Jullian <***@exbang.com>
To: Michael Gogins <***@nyc.pipeline.com>
Cc: music-dsp list <music-***@shoko.calarts.edu>; csound list
<***@maths.ex.ac.uk>
Date: Thursday, June 17, 1999 8:42 AM
Subject: Re: Csound and other synthesis systems


>Michael Gogins wrote:
>>
>> Another misconception: these days, Java IS fast. I do all my new DSP
coding
>> in Java. Java with best compilers is now about 1/2 the speed of C++. This
is
>> fast enough.
>
>Don't you think a factor of 2 is a lot ? Pity to waste half of your cpu
power
>for the beauty of no recompile. Non-platform specific C or C++ code might
be
>just as well.
>--
>Greetings,
>Michel
>.........................................................................
> Michel Jullian Directeur General email ***@exbang.com
> Exbang Industries S.A.
> Mas Chauvain route de Villeneuve tel +33(0) 499 529 878
> Maurin 34970 Lattes France fax +33(0) 499 529 879
>.........................................................................
>
>


dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
Michael Gogins
1999-06-17 23:17:52 UTC
Permalink
Paul has understood what I'm shooting for here, I think. What is going to
happen in music, I'm becoming increasingly certain, is that there will be
"frameworks" such as (for example) Cubase VST, Cool Edit Pro, Pro Tools, or
Buzz (to choose examples of the same basic idea from a wildly diverse set of
worlds) that handle user input and output, and sound input and output; the
actual music machinery is then plugins for this framework; and some of these
plugins will implement complete languages (like Csound or like
SuperCollider).


>>I know of no Java that is capable of running in real time with performance
>>guarantees and able to run in an interrupt routine where memory allocation
>>is illegal. SuperCollider was designed to be able to do this.
>
....

>i am at a loss to understand why you chose to do things in an
>interrupt routine. i guess i am just too much of a unix head to grok
>the Mac (and maybe Windows) world.
>
>>Third, the SC virtual machine is C which is far more portable than Java.
>
>Michael's idea, I think, is to not write the VM in Java, but to use a
>C implementation to support Java's "native methods" (i.e. things that
>appear to be builtins in Java). I'm not attracted to this idea all
>that much, but it seems like quite a reasonable one to me.
>



dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
Michel Jullian
1999-06-18 09:38:53 UTC
Permalink
Michael Gogins wrote:
>
> Paul has understood what I'm shooting for here, I think. What is going to
> happen in music, I'm becoming increasingly certain, is that there will be
> "frameworks" such as (for example) Cubase VST, Cool Edit Pro, Pro Tools, or
> Buzz (to choose examples of the same basic idea from a wildly diverse set of
> worlds) that handle user input and output, and sound input and output; the
> actual music machinery is then plugins for this framework; and some of these
> plugins will implement complete languages (like Csound or like
> SuperCollider).

I agree 100% on this, as may be clear from some of my other posts. This way,
_any_ musician can play your music machinery with his everyday's tools, and
the dsp programmer can get on with dsp (multiplatform code, hopefully) rather
than flashy platform-specific GUIs.

Now what if, in my sequencer, I affect to each of the n tracks of my song a
different csound orchestra ? What would be nice would be that when the
sequencer reloads my song, it instantiates automatically the csound dll n
times (which it will do), and each time with the right orchestra (how ?). I'm
not sure the vst2 spec will allow for "variable geometry" synths of the kind
of Csound or SuperCollider, I hope it will. Maybe one can achieve this by
affecting one of the 16000*128 (a lot, but still limited) or so MIDI
bank/program pairs to each orc file ?

But that doesnt look quite right : an orc is more akin to a synth than csound
itself. So maybe the way to go is for csound to save (compile ?) orcs
themselves as vst plugins, as I suggested in another post. There may be an
easy way to do that : a very lightweight orc plugin which contains little more
than the text of the orc and just calls the "heavyweight" csound plugin to do
the job.

--
Greetings,
Michel
.........................................................................
Michel Jullian Directeur General email ***@exbang.com
Exbang Industries S.A.
Mas Chauvain route de Villeneuve tel +33(0) 499 529 878
Maurin 34970 Lattes France fax +33(0) 499 529 879
.........................................................................



dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
James McCartney
1999-06-18 00:38:47 UTC
Permalink
At 5:17 PM -0600 6/17/99, Michael Gogins wrote:
>Paul has understood what I'm shooting for here, I think. What is going to
>happen in music, I'm becoming increasingly certain, is that there will be
>"frameworks" such as (for example) Cubase VST, Cool Edit Pro, Pro Tools, or
>Buzz (to choose examples of the same basic idea from a wildly diverse set of
>worlds) that handle user input and output, and sound input and output; the
>actual music machinery is then plugins for this framework; and some of these
>plugins will implement complete languages (like Csound or like
>SuperCollider).

OK I see. Well in this respect BeOS is ahead because their MediaKit
already implements a way for media components to talk to each other.
The downside is that it is a very complex API and you must use C++.

Such a framework on Linux would be very interesting.

There is no reason SC could not be a plug in for VST, etc, but
it would be a very fat one.



--- james mccartney ***@audiosynth.com http://www.audiosynth.com
If you have a PowerMac check out SuperCollider2, a real time synth program:
<ftp://www.audiosynth.com/pub/updates/SC2.1.5.sea.hqx>





dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
Thomas Hudson
1999-06-18 00:13:11 UTC
Permalink
James McCartney wrote:
>
> OK I see. Well in this respect BeOS is ahead because their MediaKit
> already implements a way for media components to talk to each other.
> The downside is that it is a very complex API and you must use C++.
>
> Such a framework on Linux would be very interesting.
>
I actually started this. With the ALSA sequencer it was easy to
implement the MidiKit classes. Though once I finished, I discovered
the signal mechanisms in Gtk--, which allow unrelated classes to be
connected to receive signals from each other. So I decided to implement
my classes using this mechanism instead of deriving from the MidiKit
base classes to implement functionality. I had never liked the
approach of requiring derivation in order to get functionality. It
seems to always cause code-bloat.

Thomas

dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
Matt J. Ingalls
1999-06-18 02:01:29 UTC
Permalink
On Thu, 17 Jun 1999, James McCartney wrote:

> OK I see. Well in this respect BeOS is ahead because their MediaKit
> already implements a way for media components to talk to each other.

im surprised Be (and others) arent hype-ing this. basically the OS
becomes the "framework" and apps themselves become the "plug-ins" -
and if these little effects apps all are "replicants" you could turn your
workspace/desktop into a "virtual studio" (could you not?) -> a fully
configurable array of fx boxes, graphic displays, etc..

-matt


dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
pete moss
1999-06-18 03:30:59 UTC
Permalink
so with all this talk about OS and dev platforms, does anyone know if
BeOS is ready for primetime? in other words, can i _do_ anything with
it, or is it still in development?

:P




"Matt J. Ingalls" wrote:
>
> On Thu, 17 Jun 1999, James McCartney wrote:
>
> > OK I see. Well in this respect BeOS is ahead because their MediaKit
> > already implements a way for media components to talk to each other.
>
> im surprised Be (and others) arent hype-ing this. basically the OS
> becomes the "framework" and apps themselves become the "plug-ins" -
> and if these little effects apps all are "replicants" you could turn your
> workspace/desktop into a "virtual studio" (could you not?) -> a fully
> configurable array of fx boxes, graphic displays, etc..
>
> -matt
>
> dupswapdrop: the music-dsp mailing list and website
> http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html

dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
James McCartney
1999-06-18 04:46:41 UTC
Permalink
At 9:30 PM -0600 6/17/99, pete moss wrote:
>so with all this talk about OS and dev platforms, does anyone know if
>BeOS is ready for primetime? in other words, can i _do_ anything with
>it, or is it still in development?

I just got my regular (not beta) 4.5 release copy in the mail today.
This has the complete MediaKit included.


--- james mccartney ***@audiosynth.com http://www.audiosynth.com
If you have a PowerMac check out SuperCollider2, a real time synth program:
<ftp://www.audiosynth.com/pub/updates/SC2.1.5.sea.hqx>





dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
Caliban Tiresias Darklock
1999-06-18 04:22:13 UTC
Permalink
On 10:30 PM 6/17/99 -0500, I personally witnessed pete moss jumping up to say:
>
>so with all this talk about OS and dev platforms, does anyone know if
>BeOS is ready for primetime? in other words, can i _do_ anything with
>it, or is it still in development?

I don't run Be, currently, but I watch it closely and have been shallowly
involved with it from a development standpoint for a couple years. I have a
finger in it, but that's about all.

I would say that BeOS is about as ready for prime time as Linux is.
However, where it is really lacking is hardware support; for example, the
last time I checked, it did not support *any* sound card other than the
AWE64. If I'd had an AWE64, I would have been tickled pink, but I have an
AWE32 with 28 (32, actually, but the SB says it's 28 so I guess it can't
address the last 4) megs of RAM onboard. A comparable AWE64 would have cost
$600. (Now we have the SBLive, which I can't put RAM on at all, and instead
I have to steal system RAM from the rest of my machine. Yeah, Creative *is*
making huge strides in audio hardware... backwards.) So while I could run
Be, I got no sound, and I was primarily interested in Be as a dedicated
music workstation O/S -- lots of really good MIDI stuff comes out for Be in
the shareware and freeware marketplace.

What Be does have that Linux doesn't is a really *good* windowing
interface. It's like a cross between NeXT, Windows, and a Mac... it's added
a great many interface wins which Microsoft continues to resist, and looks
and works quite well. Plus you can run it on Mac hardware *or* PC hardware,
which really kicks ass. And it's *pretty*, too. Mac, Windows, X, no dice --
only BeOS makes me go "oOoOo" over its interface.

If I ever migrate my whole collection of machines to one O/S, it will be
BeOS. IMO, BeOS wins where Linux loses, and loses where Linux wins. But
it's gaining. Right now they're about even, but I would expect the gap will
narrow over time until Be comes out the clear winner.

-----
| Caliban Tiresias Darklock ***@darklock.com
| Darklock Communications http://www.darklock.com/
| U L T I M A T E U N I V E R S E I S N O T D E A D
| 774577496C6C6E457645727355626D4974H -=CABAL::3146=-

dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
Mike Ricos
1999-06-18 05:10:11 UTC
Permalink
I've tinkered with BeOS rev 4 for Intel for a few months and agree with Caliban
about the status of BeOS: it has a nice interface, is fast, and is probably the
best bet for next generation of PC audio processing. Latency as low as 3 mSec has
been reported by several sources but I have not measured it personally.

Soundcard support beyond SoundBlaster is almost non-existent, but Marc Schefer's
home grown driver for Turtle Beach's Fiji/Pinnacle card works fine:

http://home.iprolink.ch/~mschefer/ (It does not support MIDI)

Supposedly the just released rev 4.5 has more hardware support but I could not
find details at the Be website.

FWIW,

Mike Ricos


dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
Benjamin GOLINVAUX
1999-06-18 09:52:28 UTC
Permalink
> If I ever migrate my whole collection of machines to one O/S, it will be
> BeOS. IMO, BeOS wins where Linux loses, and loses where Linux wins. But
> it's gaining. Right now they're about even, but I would expect the gap
will
> narrow over time until Be comes out the clear winner.
>

I would say that BeOS is ready for prime time too.

The sound card support is getting better and there will soon be cards of
various qualities supported.

pro : Event Layla (driver to be released in July), Aardvark 20/20, cards
based on Envy24 chipset (Seasound, Terratec 8 in/out), RME/Audio

good : SBLive (in 4.5 ?),AWE64, TBeach Pinnacle

cheap : AWE32, SB16, Opti, etc...


The C++ IDE is really nice (I think the debugger is quite poor, though, at
least for someone used to Visual C++)

The gui api is _GREAT_ ! I'm used to MFC on visual C++ and I can tell you
the Be api is another world.

Furthermore, the newsgroup support is starting to grow and the company
support is really good too (I've personally had contact with an engineer
from the MediaKit team who gave me detailed help even though I wasn't paying
a cent for support. The guys at Microsoft can not even _imagine_ doing that)

So I'd recommend it for anyone doing audio stuff (BTW : One detail I liked
in BeOS is the ability to extract _digital_ audio from CD without pops with
a _regular_ IDE drive at full speed.... Great for good quality dsp tests.)

So... use Linux for web stuff, word processing, gamez, database...

And use BeOS to develop audio software (and record, process and compose
music and soundtracks when there is audio software available)

Benjamin











dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
Paul Barton-Davis
1999-06-18 03:58:10 UTC
Permalink
>I actually started this. With the ALSA sequencer it was easy to
>implement the MidiKit classes. Though once I finished, I discovered
>the signal mechanisms in Gtk-- ...

Thomas - be sure to switch to Karl Nelson's new implementation of
this, libsigc++, which greatly reduces both the memory and run-time
cost of signal sending and receiving. Gtk-- will use this in some
RSN/future version.

http://www.ece.ucdavis.edu/~kenelson/libsigc++/

Quasimodo uses this for all non-GUI inter-object signalling. Because
the GUI is GTK, it uses the current Gtk-- method, but these will
obviously become the some thing as soon as Gtk-- switches.

--p

dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
Michal Jurewicz
1999-06-18 06:58:11 UTC
Permalink
At 10:30 PM 6/17/99 -0500, you wrote:
>so with all this talk about OS and dev platforms, does anyone know if
>BeOS is ready for primetime? in other words, can i _do_ anything with
>it, or is it still in development?
>
>:P

Supposedly yes:

There is an interesting reading about Media Kit at:

http://www-classic.be.com/developers/April99/BeDCtranscripts/intro1.html



Michal @ Mytek


*********************************************
http://www.mytekdigital.com >>>>>>

24 bit 48/96 k Digital Audio Converters

DAW 9624 (tm) , D-Master 9624 (tm)

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

dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
f***@m9ndfukc.com
1999-06-18 10:44:00 UTC
Permalink
>Whatever your religious objections to Windows,

if you create

>if you create a
>cross-platform virtual machine that works with Java, then you get it to run
>on Linux (or BeOS if BeOS have a Java virtual machine) and, without hurting
>anyone on those other platforms, it also runs on Windows where there are
>lots and lots of musicians who could use SuperCollider.

personally

>I started on Unix and moved to Windows not for religious reasons, but
>because

an employee

>it made my musical life happen at home and more cheaply than any
>other way without really losing any vital functionality.

I started

>I personally believe

where bl!ef = knouledge !=

>that some virtual-machine system is bound to run almost
>all software in the end.

!n dze end du = losing vital functionality
I think where bl!ef = knouledge != !n dze end


>I think

descend

>Java, its descendent,

engl!sch

>or something like it

=cw4t7abs

>will end up running on everything from supercomputers to watches.

!= ess. plz updat watch

>I think

religious akt!v!t!


>this will happen because

1 != ztajt bkausz ma!z _ warum

>software is more expensive than hardware

1

>and
>general-purpose software is cheaper than special-purpose software.

foto = ultra cheap auss!

>Note how
>the Ptolemy DSP project at UCB for the Navy has moved from C++ to Java in
>the past two years.
>Also Roldan Pozo and other big guns in numerics and
>supercomputing are pushing Java Grande because, I suspect, they anticipate
>distributed Java apps that can do more than any single app on any single
>machine.

konztataz!on
.Navy + .edu + other .big guns
!= kan wr!te oun zuprkol!dr.

james mccartney - 1 single machine
outper4mz .Navy + .edu + other .big guns

konztataz!on - all progresz = takex plasz at dze per!fer!


>>>I would love if it SuperCollider:
>>>
>>>(a) ran on Windows

+

>>If you have a PowerMac check out SuperCollider2, a real time synth program:
>><ftp://www.audiosynth.com/pub/updates/SC2.1.5.sea.hqx>


konztataz!on - all progresz = takex plasz at dze per!fer!



dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
Continue reading on narkive:
Loading...