| Message written at 26 Jun 1999 14:53:50 +0100
thank you to all who sent me suggestions, examples and comments. I
have fixed it now -- naturally it was not in the lines I was reading!
For those with sources, in follow.c line 29 change
FLOAT sig = *++in;
to
FLOAT sig = *in++;
and that is all.
==John ffitch
PS I still think there is a problem with soundin sometimes; not
tracked that yet
Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa09984;
26 Jun 99 15:33 BST
Received: from [144.173.6.14] (helo=exeter.ac.uk)
by shaun.maths.bath.ac.uk with esmtp (Exim 2.12 #1)
id 10xtWd-0004OI-00
for jpff@maths.bath.ac.uk; Sat, 26 Jun 1999 15:33:47 +0100
Received: from noether [144.173.8.10] by hermes via SMTP (PAA07813); Sat, 26 Jun 1999 15:30:33 +0100 (BST)
Received: from exeter.ac.uk by maths.ex.ac.uk; Sat, 26 Jun 1999 15:30:21 +0100
Received: from agora.stm.it [195.62.32.1] by hermes via ESMTP (PAA13238); Sat, 26 Jun 1999 15:30:19 +0100 (BST)
Received: from agora.stm.it (rm2-859.tiscalinet.it [212.123.85.97]) by agora.stm.it (8.9.2/8.8.5) with ESMTP id QAA10567 for ; Sat, 26 Jun 1999 16:30:16 +0200 (ITADST)
Message-ID: <37748F1C.5EAF6AB3@agora.stm.it>
Date: Sat, 26 Jun 1999 10:28:12 +0200
From: Gabriel Maldonado
X-Mailer: Mozilla 4.5 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Csound Mailing List
Subject: Re: RT MIDI In -> both Csound and MIDI file?
References: <199906260343.XAA19678@renoir.op.net> <37745F2F.4ECDC14B@ulster.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk
New opcodes of DirectCsound 'foutk', 'fouti', 'fiopen', 'foutir', 'fin',
'fink' and 'fini' can do this task, if properly used, even without
recording a MIDI file. Maybe John Fitch will decide to port them in
standard version, one day (and I hope it):
MANUAL
------
fout, foutk, fouti, foutir, fiopen
fout "ifilename", iformat, aout1 [, aout2, aout3,.... ,aoutN]
foutk "ifilename", iformat, kout1 [, kout2, kout3,....,koutN]
fouti ihandle, iformat, iflag, iout1 [, iout2, iout3,....,ioutN]
foutir ihandle, iformat, iflag, iout1 [, iout2, iout3,....,ioutN]
ihandle fiopen "ifilename",imode
DESCRIPTION
fout, foutk, fouti and foutir output N audio, k or i-rate signals to a
specified file of N channels.
fiopen can be used to open a file in one of the specified modes.
INITIALIZATION
ifilename - a double-quote delimited string file name
iformat - a flag to choose output file format:
for fout and foutk only:
0 - 32-bit floating point samples without header (binary PCM
multichannel file)
1 - 16-bit integers without header (binary PCM multichannel file)
2 - 16-bit integers with .wav type header (Microsoft WAV mono or stereo
file)
for fouti and foutir only:
0 - floating point in text format
1 - 32-bit floating point in binary format
iflag - choose the mode of writing to the ascii file (valid only in
ascii mode; in binary mode iflag has no meaning, but it must be present
anyway).
iflag can be a value choosen among the following:
0 - line of text without instrument prefix
1 - line of text with instrument prefix (see below)
2 - reset the time of instrument prefixes to zero (to be used only in
some particular cases. See below)
iout,... ioutN - values to be written to the file.
imode - choose the mode of opening the file.
imode can be a value choosen among the following:
0 - open a text file for writing
1 - open a text file for reading
2 - open a binary file for writing
3 - open a binary file for reading
PERFORMANCE
aout1,... aoutN - signals to be written to the file.
kout1,...koutN - signals to be written to the file.
fout (file output) writes samples of audio signals to a file with any
number of channels. Channel number depends by the number of
aoutN variables (i.e. a mono signal with only an a-rate argument, a
stereo signal with two a-rate arguments etc.) Maximum number of
channels is fixed to 64.
More fout opcodes can be present in the same instrument, referring to
different files.
Notice that, differently by out, outs and outq, fout does not zeroes the
audio variable, so you must provide a zeroing after calling fout if
poliphony is used. You can use incr and clear opcodes for this task.
foutk operates in the same way of fout, but with k-rate signals. iformat
can be set only to 0 or 1.
fouti and foutir write i-rate values to a file. The main use of these
opcodes is to generate a score file during a realtime session. For
this purpose the user should set iformat to 0 (text file output) and
iflag to 1, which enable the output of a prefix consisting of the
following strings:
i num actiontime duration
before the values of iout1...ioutN arguments. Prefix is referring to
instrument number, action time and duration of current note.
The difference of fouti and foutir is that, in the case of fouti, when
iflag is set to 1, the duration of the first opcode is undefined (so it
is replaced by a dot ) wheras in the case of foutir is defined at the
end of note, so the corresponding text line is written only at the end
of the current note (in order to recognize its duration). The
corresponding file is linked by the ihandle value generated by fiopen
opcode (see below). So fouti and foutir can be used to generate a Csound
score while playing a realtime session.
fiopen opens a file to be used by the foutX opcodes. It must be defined
externally by any instruments, in the header section.
It returns a number ihandle, which is univocally referring to the opened
file.
Notice that fout and foutk can use both a string containing a file
pathname or a handle-number generated by fiopen, wheras in the
case of fouti and foutir, the target file can be only specified by means
of a handle-number.
fin, fink, fini
fin "ifilename", iskipframes, iformat, ain1 [, ain2, ain3,.... ,ainN]
fink "ifilename", iskipframes, iformat, kin1 [, kin2, kin3,.... ,kinN]
fini "ifilename", iskipframes, iformat, in1 [, in2, in3,.... ,inN]
DESCRIPTION
read signals from a file (at a, k, and i-rate)
INITIALIZATION
ifilename - input file name (can be a string or a handle number
generated by fiopen)
iskipframes - number of frames to skip at the start (every frame
contains a sample of each channel)
iformat - a number specifying the input file format:
for fin and fink:
0 - 32 bit floating points without header
1 - 16 bit integers without header
for fini:
0 - floating points in text format (loop; see below)
1 - floating points in text format (no loop; see below)
2 - 32 bit floating points in binary format (no loop)
fin (file input) is the complement of fout: it reads a multi channel
file to generate audio rate signals. At present time no header is
supported for file format. The user must be sure that the number of
channel of the input file is the same of the number of ainX
arguments
fink is the same as fin, but operates at k-rate.
fini is the complement of fouti and foutir, it reads the values each
time the corresponding instrument note is activated.
When iformat is set to 0, if the end of file is reached the file pointer
is zeroed, restarting the scanning from the beginning.
When iformat is set to 1 or 2 no loop is enabled, so at the end of file
the corresponding variables will be filled with zeroes.
Paul Winkler wrote:
>
> Paul Barton-Davis wrote:
>
> > (dd if=/dev/midi00 bs=1 | tee /dev/midi01 | cat - my-midi-session) &
> > csound -M /dev/midi02
>
> (snip)
>
> > % mkfifo /tmp/csound-midi-fifo
> > % dd if=/dev/midi00 bs=1 | \
> > tee my-midi-session > /tmp/csound-midi-fifo &
> > % csound -M /tmp/csound-midi-fifo ...
>
> Paul, I haven't tried either of your tee tricks -- no time right now, I
> just moved and still haven't unpacked my midi controller -- but I
> followed the logic and it seems to me they _should_ work ... except that
> won't the midi file created contain no timing information?? It's just a
> dump of raw midi data, right? Or am I mistaken?
>
> --
>
> ---------------- paul winkler ------------------
> slinkP arts: music, sound, illustration, design, etc.
>
> zarmzarm@hotmail.com --or-- slinkp AT ulster DOT net
> http://members.tripod.com/~slinkP/
> ======================================================
--
Gabriel Maldonado
http://web.tiscalinet.it/G-Maldonado/home2.htm
Received: from wallace.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa10011;
26 Jun 99 15:41 BST
Received: from [144.173.6.14] (helo=exeter.ac.uk)
by wallace.maths.bath.ac.uk with esmtp (Exim 2.12 #1)
id 10xtdy-0000Ql-00
for jpff@maths.bath.ac.uk; Sat, 26 Jun 1999 15:41:22 +0100
Received: from noether [144.173.8.10] by hermes via SMTP (PAA04586); Sat, 26 Jun 1999 15:38:08 +0100 (BST)
Received: from exeter.ac.uk by maths.ex.ac.uk; Sat, 26 Jun 1999 15:37:56 +0100
Received: from root@smtp-out-004.wanadoo.fr [193.252.19.87] by hermes via ESMTP (PAA06140); Sat, 26 Jun 1999 15:37:56 +0100 (BST)
Received: from andira.wanadoo.fr [193.252.19.152] by wanadoo.fr
for
Paris Sat, 26 Jun 1999 16:37:56 +0200 (MET DST)
Received: from exbang.com (193.250.98.85) by andira.wanadoo.fr; 26 Jun 1999 16:38:14 +0200
Message-ID: <377501AF.6263FB8B@exbang.com>
Date: Sat, 26 Jun 1999 16:37:29 +0000
From: Michel Jullian
Reply-To: mj@exbang.com
X-Mailer: Mozilla 4.04 (Macintosh; I; PPC)
MIME-Version: 1.0
To: Csound List
CC: music-dsp@shoko.calarts.edu, JavaSound
Subject: Re: Proposal for a new version of Csound
References: <002201bebf98$71f57b00$79d496c0@Realizer.ngt.sungard.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk
Michael Gogins wrote:
> To summarize, the idea is to do a kernel rewrite of Csound that implements
> the existing orchestra language, score language, commands, and behavior in a
> shared library.
That will certainly expand the scope of Csound, and pave the way to (my dream,
as some may have noticed) compilation of Csound instruments as lightweight
VST2 dlls relying on the shared library for DSP work.
> Completely platform-independent kernel written in ANSI C using only the
> runtime library.
Why not C++ ? Aren't UGs best modeled as objects (state + behavior) ?
> Plugin unit generators.
> Plugin function tables.
Flexible growth for Csound. Will direct loading of Csound Plugin UGs by other
frameworks be allowed ? Why not make it a universal Plugin interface for UGs ?
> Java interface that integrates with the JavaSound API.
Java GUI and I/O code on top of fast multiplatform DSP code. That's a perfect
combination IMHO.
>If anyone is interested in working with me on this, email me.
I hope there will be many candidates. I doubt I'll be able to participate in
the coding (i wish i was government funded like you all lucky academics), but
as a potential user I am very interested and would love to be informed of, and
if I can at all contribute to, this project's developments.
In any case thank you Michael for this very constructive proposal.
--
Greetings,
Michel
.........................................................................
Michel Jullian Directeur General email mj@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
.........................................................................
Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa10049;
26 Jun 99 16:01 BST
Received: from [156.3.140.104] (helo=shoko.calarts.edu)
by shaun.maths.bath.ac.uk with esmtp (Exim 2.12 #1)
id 10xtxt-0004Oi-00
for jpff@maths.bath.ac.uk; Sat, 26 Jun 1999 16:01:57 +0100
Received: (from majordom@localhost)
by shoko.calarts.edu (8.9.3/8.9.3) id HAA27495
for music-dsp-outgoing; Sat, 26 Jun 1999 07:38:01 -0700 (PDT)
X-Authentication-Warning: shoko.calarts.edu: majordom set sender to owner-music-dsp@shoko.calarts.edu using -f
Received: from wanadoo.fr (root@smtp-out-004.wanadoo.fr [193.252.19.87])
by shoko.calarts.edu (8.9.3/8.9.3) with ESMTP id HAA27491
for ; Sat, 26 Jun 1999 07:37:59 -0700 (PDT)
Received: from andira.wanadoo.fr [193.252.19.152] by wanadoo.fr
for
Paris Sat, 26 Jun 1999 16:37:56 +0200 (MET DST)
Received: from exbang.com (193.250.98.85) by andira.wanadoo.fr; 26 Jun 1999 16:38:14 +0200
Message-ID: <377501AF.6263FB8B@exbang.com>
Date: Sat, 26 Jun 1999 16:37:29 +0000
From: Michel Jullian
X-Mailer: Mozilla 4.04 (Macintosh; I; PPC)
MIME-Version: 1.0
To: Csound List
CC: music-dsp@shoko.calarts.edu, JavaSound
Subject: Re: Proposal for a new version of Csound
References: <002201bebf98$71f57b00$79d496c0@Realizer.ngt.sungard.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-music-dsp@shoko.calarts.edu
Precedence: bulk
Reply-To: music-dsp@shoko.calarts.edu
Michael Gogins wrote:
> To summarize, the idea is to do a kernel rewrite of Csound that implements
> the existing orchestra language, score language, commands, and behavior in a
> shared library.
That will certainly expand the scope of Csound, and pave the way to (my dream,
as some may have noticed) compilation of Csound instruments as lightweight
VST2 dlls relying on the shared library for DSP work.
> Completely platform-independent kernel written in ANSI C using only the
> runtime library.
Why not C++ ? Aren't UGs best modeled as objects (state + behavior) ?
> Plugin unit generators.
> Plugin function tables.
Flexible growth for Csound. Will direct loading of Csound Plugin UGs by other
frameworks be allowed ? Why not make it a universal Plugin interface for UGs ?
> Java interface that integrates with the JavaSound API.
Java GUI and I/O code on top of fast multiplatform DSP code. That's a perfect
combination IMHO.
>If anyone is interested in working with me on this, email me.
I hope there will be many candidates. I doubt I'll be able to participate in
the coding (i wish i was government funded like you all lucky academics), but
as a potential user I am very interested and would love to be informed of, and
if I can at all contribute to, this project's developments.
In any case thank you Michael for this very constructive proposal.
--
Greetings,
Michel
.........................................................................
Michel Jullian Directeur General email mj@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
Received: from wallace.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa10153;
26 Jun 99 17:16 BST
Received: from [144.173.6.14] (helo=exeter.ac.uk)
by wallace.maths.bath.ac.uk with esmtp (Exim 2.12 #1)
id 10xv8O-0000Rn-00
for jpff@maths.bath.ac.uk; Sat, 26 Jun 1999 17:16:52 +0100
Received: from noether [144.173.8.10] by hermes via SMTP (RAA00750); Sat, 26 Jun 1999 17:13:24 +0100 (BST)
Received: from exeter.ac.uk by maths.ex.ac.uk; Sat, 26 Jun 1999 17:13:12 +0100
Received: from smtp0.mindspring.com [207.69.200.30] by hermes via ESMTP (RAA14658); Sat, 26 Jun 1999 17:13:11 +0100 (BST)
Received: from Realizer (user-2ive2jn.dialup.mindspring.com [165.247.10.119])
by smtp0.mindspring.com (8.8.5/8.8.5) with SMTP id MAA03075;
Sat, 26 Jun 1999 12:13:06 -0400 (EDT)
Message-ID: <000c01bebfef$0ee30300$79d496c0@Realizer.ngt.sungard.com>
From: Michael Gogins
To: mj@exbang.com, Csound List
MMDF-Warning: Parse error in original version of preceding line at UK.AC.Bath.maths.omphalos
Cc: music-dsp@shoko.calarts.edu, JavaSound
MMDF-Warning: Parse error in original version of preceding line at UK.AC.Bath.maths.omphalos
Subject: Re: Proposal for a new version of Csound
Date: Sat, 26 Jun 1999 12:15:03 -0400
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk
Thanks for your response. I will address your points in the order raised.
>Why not C++ ? Aren't UGs best modeled as objects (state + behavior) ?
C is still a little bit faster, and Csound is written almost entirely in C.
>
>> Plugin unit generators.
>> Plugin function tables.
>
>Flexible growth for Csound. Will direct loading of Csound Plugin UGs by
other
>frameworks be allowed ? Why not make it a universal Plugin interface for
UGs ?
Fortunately or unfortunately, Csound UGs need access to global objects in
the Csound kernel, notably various rate variables and the function table
array. They cannot really work in isolation. If the UG "type" were changed
to perform this access through an abstract interface that other applications
could implement, it would work, but then that would be an even deeper
rewrite of Csound than I am contemplating.
>I hope there will be many candidates. I doubt I'll be able to participate
in
>the coding (i wish i was government funded like you all lucky academics),
but
>as a potential user I am very interested and would love to be informed of,
and
>if I can at all contribute to, this project's developments.
I am not an academic. I have a fulltime day job as a C++ programmer.
Received: from wallace.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa10174;
26 Jun 99 17:27 BST
Received: from [156.3.140.104] (helo=shoko.calarts.edu)
by wallace.maths.bath.ac.uk with esmtp (Exim 2.12 #1)
id 10xvIV-0000Rs-00
for jpff@maths.bath.ac.uk; Sat, 26 Jun 1999 17:27:19 +0100
Received: (from majordom@localhost)
by shoko.calarts.edu (8.9.3/8.9.3) id JAA28455
for music-dsp-outgoing; Sat, 26 Jun 1999 09:13:16 -0700 (PDT)
X-Authentication-Warning: shoko.calarts.edu: majordom set sender to owner-music-dsp@shoko.calarts.edu using -f
Received: from smtp0.mindspring.com (smtp0.mindspring.com [207.69.200.30])
by shoko.calarts.edu (8.9.3/8.9.3) with ESMTP id JAA28451
for ; Sat, 26 Jun 1999 09:13:14 -0700 (PDT)
Received: from Realizer (user-2ive2jn.dialup.mindspring.com [165.247.10.119])
by smtp0.mindspring.com (8.8.5/8.8.5) with SMTP id MAA03075;
Sat, 26 Jun 1999 12:13:06 -0400 (EDT)
Message-ID: <000c01bebfef$0ee30300$79d496c0@Realizer.ngt.sungard.com>
From: Michael Gogins
To: mj@exbang.com, Csound List
MMDF-Warning: Parse error in original version of preceding line at UK.AC.Bath.maths.omphalos
Cc: music-dsp@shoko.calarts.edu, JavaSound
MMDF-Warning: Parse error in original version of preceding line at UK.AC.Bath.maths.omphalos
Subject: Re: Proposal for a new version of Csound
Date: Sat, 26 Jun 1999 12:15:03 -0400
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-music-dsp@shoko.calarts.edu
Precedence: bulk
Reply-To: music-dsp@shoko.calarts.edu
Thanks for your response. I will address your points in the order raised.
>Why not C++ ? Aren't UGs best modeled as objects (state + behavior) ?
C is still a little bit faster, and Csound is written almost entirely in C.
>
>> Plugin unit generators.
>> Plugin function tables.
>
>Flexible growth for Csound. Will direct loading of Csound Plugin UGs by
other
>frameworks be allowed ? Why not make it a universal Plugin interface for
UGs ?
Fortunately or unfortunately, Csound UGs need access to global objects in
the Csound kernel, notably various rate variables and the function table
array. They cannot really work in isolation. If the UG "type" were changed
to perform this access through an abstract interface that other applications
could implement, it would work, but then that would be an even deeper
rewrite of Csound than I am contemplating.
>I hope there will be many candidates. I doubt I'll be able to participate
in
>the coding (i wish i was government funded like you all lucky academics),
but
>as a potential user I am very interested and would love to be informed of,
and
>if I can at all contribute to, this project's developments.
I am not an academic. I have a fulltime day job as a C++ programmer.
dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
Received: from wallace.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa10204;
26 Jun 99 17:42 BST
Received: from [144.173.6.14] (helo=exeter.ac.uk)
by wallace.maths.bath.ac.uk with esmtp (Exim 2.12 #1)
id 10xvXV-0000S8-00
for jpff@maths.bath.ac.uk; Sat, 26 Jun 1999 17:42:49 +0100
Received: from noether [144.173.8.10] by hermes via SMTP (RAA06916); Sat, 26 Jun 1999 17:38:09 +0100 (BST)
Received: from exeter.ac.uk by maths.ex.ac.uk; Sat, 26 Jun 1999 17:37:58 +0100
Received: from root@renoir.op.net [209.152.193.4] by hermes via ESMTP (RAA17349); Sat, 26 Jun 1999 17:37:56 +0100 (BST)
Received: from someip.ppp.op.net (d-bm2-06.ppp.op.net [209.152.194.38]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id MAA18250; Sat, 26 Jun 1999 12:37:54 -0400 (EDT)
Message-Id: <199906261637.MAA18250@renoir.op.net>
To: Michael Gogins
Cc: csound@maths.ex.ac.uk
Subject: Re: Proposal for a new version of Csound
In-reply-to: Your message of "Sat, 26 Jun 1999 12:15:03 EDT."
<000c01bebfef$0ee30300$79d496c0@Realizer.ngt.sungard.com>
Date: Sat, 26 Jun 1999 12:44:37 -0400
From: Paul Barton-Davis
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk
>Fortunately or unfortunately, Csound UGs need access to global objects in
>the Csound kernel, notably various rate variables and the function table
>array. They cannot really work in isolation. If the UG "type" were changed
>to perform this access through an abstract interface that other applications
>could implement, it would work, but then that would be an even deeper
>rewrite of Csound than I am contemplating.
Michael - this isn't true. There is no reason to change the UG "type"
in order to provide access to rate variables and function tables.
I know this because I've done it in Quasimodo. This is certainly true
for Unix dynamic libraries anyway, and I was under the impression that
the Windows DLL's worked similarly. Perhaps not.
BTW, Quasimodo also changed the UG argument type to be a C++ object,
which allows much greater flexibility and also allows you to use the
compiler to take of allocation, which avoids some of the silly
problems with alignment that regular Csound has had on 64 bit machines.
However, the object looks identical from the point of view of an
opcode function.
Also, as far as C++ goes, although its true there is often a small
speed penalty even for identical code, in the places where it matters
(execution opcode functions), egcs spits out almost identical code for
C or C++ compilation. There's really nowhere else in Csound where the
difference between the two languages makes a significant difference in
terms of speed.
--p
Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa10217;
26 Jun 99 17:48 BST
Received: from [144.173.6.14] (helo=exeter.ac.uk)
by shaun.maths.bath.ac.uk with esmtp (Exim 2.12 #1)
id 10xvcg-0004Pk-00
for jpff@maths.bath.ac.uk; Sat, 26 Jun 1999 17:48:10 +0100
Received: from noether [144.173.8.10] by hermes via SMTP (RAA09599); Sat, 26 Jun 1999 17:43:32 +0100 (BST)
Received: from exeter.ac.uk by maths.ex.ac.uk; Sat, 26 Jun 1999 17:43:21 +0100
Received: from root@renoir.op.net [209.152.193.4] by hermes via ESMTP (RAA17726); Sat, 26 Jun 1999 17:43:20 +0100 (BST)
Received: from someip.ppp.op.net (d-bm2-06.ppp.op.net [209.152.194.38]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id MAA18507; Sat, 26 Jun 1999 12:43:17 -0400 (EDT)
Message-Id: <199906261643.MAA18507@renoir.op.net>
To: Csound List , music-dsp@shoko.calarts.edu,
JavaSound , pbd@renoir.op.net
Subject: Re: Proposal for a new version of Csound
In-reply-to: Your message of "Sat, 26 Jun 1999 16:37:29 -0000."
<377501AF.6263FB8B@exbang.com>
Date: Sat, 26 Jun 1999 12:50:01 -0400
From: Paul Barton-Davis
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk
>> To summarize, the idea is to do a kernel rewrite of Csound that implements
>> the existing orchestra language, score language, commands, and behavior in a
>> shared library.
Why do you want to start with Csound when Quasimodo is already running
and much closer to what you're talking about than Csound ?
>> Completely platform-independent kernel written in ANSI C using only the
>> runtime library.
Ah, now there's your reason :)
I hope that you will at least consider using the Csound orchestra
parser from Quasimodo rather than hacking up another "custom parser"
like the one already in Csound.
>Why not C++ ? Aren't UGs best modeled as objects (state + behavior) ?
Indeed. Although actually, no, because of the speed penalty. This is
one area where you don't want to mess around with too many object
abstractions - its in the inner loop of Csound's execution. However,
that doesn't stop you from using some aspects of C++ for the arguments
to an opcode function, or its internals.
--p
Received: from wallace.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa10225;
26 Jun 99 17:51 BST
Received: from [144.173.6.14] (helo=exeter.ac.uk)
by wallace.maths.bath.ac.uk with esmtp (Exim 2.12 #1)
id 10xvgC-0000SD-00
for jpff@maths.bath.ac.uk; Sat, 26 Jun 1999 17:51:48 +0100
Received: from noether [144.173.8.10] by hermes via SMTP (RAA11018); Sat, 26 Jun 1999 17:47:03 +0100 (BST)
Received: from exeter.ac.uk by maths.ex.ac.uk; Sat, 26 Jun 1999 17:46:52 +0100
Received: from smtp0.mindspring.com [207.69.200.30] by hermes via ESMTP (RAA01256); Sat, 26 Jun 1999 17:46:51 +0100 (BST)
Received: from Realizer (user-2ive1ko.dialup.mindspring.com [165.247.6.152])
by smtp0.mindspring.com (8.8.5/8.8.5) with SMTP id MAA01250;
Sat, 26 Jun 1999 12:46:49 -0400 (EDT)
Message-ID: <002701bebff3$c2571e40$79d496c0@Realizer.ngt.sungard.com>
From: Michael Gogins
To: Paul Barton-Davis
Cc: csound@maths.ex.ac.uk
MMDF-Warning: Parse error in original version of preceding line at UK.AC.Bath.maths.omphalos
Subject: Re: Proposal for a new version of Csound
Date: Sat, 26 Jun 1999 12:48:17 -0400
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk
I think you may have slightly misunderstood my question.
I did not mean an abstract interface was necessary for UGs to access
function tables, only that one would be required to UGs to access function
tables exported by some other, non-Csound application hosting the UG. But I
may be wrong about this...
What do you think about this idea? Would you be open to using this
JavaCsound kernel in Quasimodo, or merging the two kernels into one (as a
shared library, it can support any number of external interfaces, including,
as I have said, Java, VST-2, Buzz machines, etc.).
-----Original Message-----
From: Paul Barton-Davis
To: Michael Gogins
Cc: csound@noether.ex.ac.uk
Date: Saturday, June 26, 1999 12:37 PM
Subject: Re: Proposal for a new version of Csound
>>Fortunately or unfortunately, Csound UGs need access to global objects in
>>the Csound kernel, notably various rate variables and the function table
>>array. They cannot really work in isolation. If the UG "type" were changed
>>to perform this access through an abstract interface that other
applications
>>could implement, it would work, but then that would be an even deeper
>>rewrite of Csound than I am contemplating.
>
>Michael - this isn't true. There is no reason to change the UG "type"
>in order to provide access to rate variables and function tables.
>I know this because I've done it in Quasimodo. This is certainly true
>for Unix dynamic libraries anyway, and I was under the impression that
>the Windows DLL's worked similarly. Perhaps not.
>
>BTW, Quasimodo also changed the UG argument type to be a C++ object,
>which allows much greater flexibility and also allows you to use the
>compiler to take of allocation, which avoids some of the silly
>problems with alignment that regular Csound has had on 64 bit machines.
>However, the object looks identical from the point of view of an
>opcode function.
>
>Also, as far as C++ goes, although its true there is often a small
>speed penalty even for identical code, in the places where it matters
>(execution opcode functions), egcs spits out almost identical code for
>C or C++ compilation. There's really nowhere else in Csound where the
>difference between the two languages makes a significant difference in
>terms of speed.
>
>--p
>
>
Received: from wallace.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa10233;
26 Jun 99 17:56 BST
Received: from [156.3.140.104] (helo=shoko.calarts.edu)
by wallace.maths.bath.ac.uk with esmtp (Exim 2.12 #1)
id 10xvki-0000SF-00
for jpff@maths.bath.ac.uk; Sat, 26 Jun 1999 17:56:28 +0100
Received: (from majordom@localhost)
by shoko.calarts.edu (8.9.3/8.9.3) id JAA28849
for music-dsp-outgoing; Sat, 26 Jun 1999 09:43:37 -0700 (PDT)
X-Authentication-Warning: shoko.calarts.edu: majordom set sender to owner-music-dsp@shoko.calarts.edu using -f
Received: from renoir.op.net (root@renoir.op.net [209.152.193.4])
by shoko.calarts.edu (8.9.3/8.9.3) with ESMTP id JAA28838
for ; Sat, 26 Jun 1999 09:43:27 -0700 (PDT)
Received: from someip.ppp.op.net (d-bm2-06.ppp.op.net [209.152.194.38]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id MAA18507; Sat, 26 Jun 1999 12:43:17 -0400 (EDT)
Message-Id: <199906261643.MAA18507@renoir.op.net>
To: Csound List , music-dsp@shoko.calarts.edu,
JavaSound , pbd@renoir.op.net
Subject: Re: Proposal for a new version of Csound
In-reply-to: Your message of "Sat, 26 Jun 1999 16:37:29 -0000."
<377501AF.6263FB8B@exbang.com>
Date: Sat, 26 Jun 1999 12:50:01 -0400
From: Paul Barton-Davis
Sender: owner-music-dsp@shoko.calarts.edu
Precedence: bulk
Reply-To: music-dsp@shoko.calarts.edu
>> To summarize, the idea is to do a kernel rewrite of Csound that implements
>> the existing orchestra language, score language, commands, and behavior in a
>> shared library.
Why do you want to start with Csound when Quasimodo is already running
and much closer to what you're talking about than Csound ?
>> Completely platform-independent kernel written in ANSI C using only the
>> runtime library.
Ah, now there's your reason :)
I hope that you will at least consider using the Csound orchestra
parser from Quasimodo rather than hacking up another "custom parser"
like the one already in Csound.
>Why not C++ ? Aren't UGs best modeled as objects (state + behavior) ?
Indeed. Although actually, no, because of the speed penalty. This is
one area where you don't want to mess around with too many object
abstractions - its in the inner loop of Csound's execution. However,
that doesn't stop you from using some aspects of C++ for the arguments
to an opcode function, or its internals.
--p
dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa10272;
26 Jun 99 18:13 BST
Received: from [144.173.6.14] (helo=exeter.ac.uk)
by shaun.maths.bath.ac.uk with esmtp (Exim 2.12 #1)
id 10xw0s-0004Q6-00
for jpff@maths.bath.ac.uk; Sat, 26 Jun 1999 18:13:10 +0100
Received: from noether [144.173.8.10] by hermes via SMTP (SAA04411); Sat, 26 Jun 1999 18:09:46 +0100 (BST)
Received: from exeter.ac.uk by maths.ex.ac.uk; Sat, 26 Jun 1999 18:09:35 +0100
Received: from root@renoir.op.net [209.152.193.4] by hermes via ESMTP (SAA08940); Sat, 26 Jun 1999 18:09:34 +0100 (BST)
Received: from op.net (d-bm2-06.ppp.op.net [209.152.194.38]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id NAA19889; Sat, 26 Jun 1999 13:09:32 -0400 (EDT)
Received: (from pbd@localhost) by op.net ($Revision: 1.2 $) id NAA04611; Sat, 26 Jun 1999 13:16:16 -0400
Date: Sat, 26 Jun 1999 13:16:16 -0400
Message-Id: <199906261716.NAA04611@op.net>
From: Paul Barton-Davis
To: csound@maths.ex.ac.uk, music-dsp@shoko.calarts.edu
Subject: Quasimodo: an overview
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk
In the wake of Michael's proposal, I think I should post a little
description of what Quasimodo is, since I think that a number of
people on both the lists this is sent to don't know enough about
it. Its purpose is not identical to Michael's idea, but the
similarities are important.
---------------------------------------------------------------------
Quasimodo is written in C++. It makes strong use of contemporary C++
techniques.
Quasimodo is a reimplementation of the Csound "engine". It uses the
same source code for the UG's as Csound (after running them through a
perl filter to fix a couple of minor details). Almost every Csound
opcode is available for Quasimodo, with the exception of those that
cannot be executed in real-time, though these will be ported
eventually. Even Sean Costello's recent additions (svfilter, hilbert,
resonz and resonr) are already part of Quasimodo (I ported them the
same day 3.55 was released).
Quasimodo contains plugin parsers for handling languages. It currently
has such parsers for the Csound orchestra and score languages, and
will soon feature other languages as well (e.g. SAOL and my own
contribution of a more C-like instrument language). The parsers are
automatically generated by Bison and flex from formal grammar
specifications of the languages, and thus can be easily altered and
extended.
UG's are handled as plugins, and are dynamically loaded if and only if
an instrument definition calls for them. You can create a new UG and
load it into a running version of Quasimodo.
Quasimodo also uses a plugin model for its user interface, and
currently comes with both a GTK+/Gtk-- based GUI and a very
non-functional command line interface.
Quasimodo supports real-time editing of instrument variables, and
real-time patching between different instruments. You can twist a knob
(real or virtual), and the value of a given variable in an instrument
will be altered as you move it. There is no latency other than
whatever audio buffering is in place. The patching system does most of
what the zak system does, but doesn't require instruments to know
whether or not they are patched together.
Quasimodo compiles Csound instruments into an internal abstract
expression tree of the kind used in other compilers, allowing
Quasimodo to potentially do optimization on instrument definitions.
Quasimodo supports real-time MIDI and other event input, and times
MIDI events separately from audio data, though the two are held in
tight synchrony. This separation allows Quasimodo to handle MIDI
correctly even when there is no audio output, and does not rely on a
run-time command line flag to do this. Quasimodo will soon support a
shared memory API allowing it to be controlled by other programs
directly.
The current GUI also supports full binding of any and all visual control
elements (knobs, sliders, buttons etc.) to MIDI controllers.
Quasimodo (will shortly) use XML for its instrument files (though we
call them "modules").
Quasimodo is multithreaded, and can take full advantage of dual CPU
platforms. A future version will take full advantage of platforms with
more than 2 processors as well.
Quasimodo supports storing function tables on disk for later use. When
used, no (explicit) data copying takes place (thanks to mmap(2)),
allowing enormous function tables to be handled efficiently.
Quasimodo uses mmap(2) for all handling of "in memory" sound files and
other data, avoiding data copying. Soundfiles and function tables are
reference counted, and will be freed when they are no longer needed.
Quasimodo uses a version of Bill Schottstaedt's sndlib for handling
soundfiles, allowing it to handle a large variety of sound file
formats.
Quasimodo is free, released under the GNU General Public License, and
is designed for operating systems that support the POSIX standard. It
currently runs on Linux and SGI IRIX. A Solaris port is underway (and
Be have expressed an interest in having it ported to BeOS). Yes, that
does mean that it does *not* run on Windows or MacOS systems. A port
to Windows would be possible; a port to the MacOS would be extremely
difficult, since the MacOS does not use preemptive scheduling.
Quasimodo is still under a great deal of development.
--p
Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa10288;
26 Jun 99 18:23 BST
Received: from [156.3.140.104] (helo=shoko.calarts.edu)
by shaun.maths.bath.ac.uk with esmtp (Exim 2.12 #1)
id 10xwB2-0004QB-00
for jpff@maths.bath.ac.uk; Sat, 26 Jun 1999 18:23:40 +0100
Received: (from majordom@localhost)
by shoko.calarts.edu (8.9.3/8.9.3) id KAA29702
for music-dsp-outgoing; Sat, 26 Jun 1999 10:09:39 -0700 (PDT)
X-Authentication-Warning: shoko.calarts.edu: majordom set sender to owner-music-dsp@shoko.calarts.edu using -f
Received: from renoir.op.net (root@renoir.op.net [209.152.193.4])
by shoko.calarts.edu (8.9.3/8.9.3) with ESMTP id KAA29698
for ; Sat, 26 Jun 1999 10:09:37 -0700 (PDT)
Received: from op.net (d-bm2-06.ppp.op.net [209.152.194.38]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id NAA19889; Sat, 26 Jun 1999 13:09:32 -0400 (EDT)
Received: (from pbd@localhost) by op.net ($Revision: 1.2 $) id NAA04611; Sat, 26 Jun 1999 13:16:16 -0400
Date: Sat, 26 Jun 1999 13:16:16 -0400
Message-Id: <199906261716.NAA04611@op.net>
From: Paul Barton-Davis
To: csound@maths.ex.ac.uk, music-dsp@shoko.calarts.edu
Subject: Quasimodo: an overview
Sender: owner-music-dsp@shoko.calarts.edu
Precedence: bulk
Reply-To: music-dsp@shoko.calarts.edu
In the wake of Michael's proposal, I think I should post a little
description of what Quasimodo is, since I think that a number of
people on both the lists this is sent to don't know enough about
it. Its purpose is not identical to Michael's idea, but the
similarities are important.
---------------------------------------------------------------------
Quasimodo is written in C++. It makes strong use of contemporary C++
techniques.
Quasimodo is a reimplementation of the Csound "engine". It uses the
same source code for the UG's as Csound (after running them through a
perl filter to fix a couple of minor details). Almost every Csound
opcode is available for Quasimodo, with the exception of those that
cannot be executed in real-time, though these will be ported
eventually. Even Sean Costello's recent additions (svfilter, hilbert,
resonz and resonr) are already part of Quasimodo (I ported them the
same day 3.55 was released).
Quasimodo contains plugin parsers for handling languages. It currently
has such parsers for the Csound orchestra and score languages, and
will soon feature other languages as well (e.g. SAOL and my own
contribution of a more C-like instrument language). The parsers are
automatically generated by Bison and flex from formal grammar
specifications of the languages, and thus can be easily altered and
extended.
UG's are handled as plugins, and are dynamically loaded if and only if
an instrument definition calls for them. You can create a new UG and
load it into a running version of Quasimodo.
Quasimodo also uses a plugin model for its user interface, and
currently comes with both a GTK+/Gtk-- based GUI and a very
non-functional command line interface.
Quasimodo supports real-time editing of instrument variables, and
real-time patching between different instruments. You can twist a knob
(real or virtual), and the value of a given variable in an instrument
will be altered as you move it. There is no latency other than
whatever audio buffering is in place. The patching system does most of
what the zak system does, but doesn't require instruments to know
whether or not they are patched together.
Quasimodo compiles Csound instruments into an internal abstract
expression tree of the kind used in other compilers, allowing
Quasimodo to potentially do optimization on instrument definitions.
Quasimodo supports real-time MIDI and other event input, and times
MIDI events separately from audio data, though the two are held in
tight synchrony. This separation allows Quasimodo to handle MIDI
correctly even when there is no audio output, and does not rely on a
run-time command line flag to do this. Quasimodo will soon support a
shared memory API allowing it to be controlled by other programs
directly.
The current GUI also supports full binding of any and all visual control
elements (knobs, sliders, buttons etc.) to MIDI controllers.
Quasimodo (will shortly) use XML for its instrument files (though we
call them "modules").
Quasimodo is multithreaded, and can take full advantage of dual CPU
platforms. A future version will take full advantage of platforms with
more than 2 processors as well.
Quasimodo supports storing function tables on disk for later use. When
used, no (explicit) data copying takes place (thanks to mmap(2)),
allowing enormous function tables to be handled efficiently.
Quasimodo uses mmap(2) for all handling of "in memory" sound files and
other data, avoiding data copying. Soundfiles and function tables are
reference counted, and will be freed when they are no longer needed.
Quasimodo uses a version of Bill Schottstaedt's sndlib for handling
soundfiles, allowing it to handle a large variety of sound file
formats.
Quasimodo is free, released under the GNU General Public License, and
is designed for operating systems that support the POSIX standard. It
currently runs on Linux and SGI IRIX. A Solaris port is underway (and
Be have expressed an interest in having it ported to BeOS). Yes, that
does mean that it does *not* run on Windows or MacOS systems. A port
to Windows would be possible; a port to the MacOS would be extremely
difficult, since the MacOS does not use preemptive scheduling.
Quasimodo is still under a great deal of development.
--p
dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html
Received: from wallace.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa10294;
26 Jun 99 18:26 BST
Received: from [144.173.6.14] (helo=exeter.ac.uk)
by wallace.maths.bath.ac.uk with esmtp (Exim 2.12 #1)
id 10xwE1-0000Sc-00
for jpff@maths.bath.ac.uk; Sat, 26 Jun 1999 18:26:45 +0100
Received: from noether [144.173.8.10] by hermes via SMTP (SAA14917); Sat, 26 Jun 1999 18:23:14 +0100 (BST)
Received: from exeter.ac.uk by maths.ex.ac.uk; Sat, 26 Jun 1999 18:23:03 +0100
Received: from root@renoir.op.net [209.152.193.4] by hermes via ESMTP (SAA02293); Sat, 26 Jun 1999 18:23:01 +0100 (BST)
Received: from someip.ppp.op.net (d-bm2-06.ppp.op.net [209.152.194.38]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id NAA20401; Sat, 26 Jun 1999 13:22:59 -0400 (EDT)
Message-Id: <199906261722.NAA20401@renoir.op.net>
To: Michael Gogins
cc: csound@maths.ex.ac.uk
Subject: Re: Proposal for a new version of Csound
In-reply-to: Your message of "Sat, 26 Jun 1999 12:48:17 EDT."
<002701bebff3$c2571e40$79d496c0@Realizer.ngt.sungard.com>
Date: Sat, 26 Jun 1999 13:29:43 -0400
From: Paul Barton-Davis
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk
>I did not mean an abstract interface was necessary for UGs to access
>function tables, only that one would be required to UGs to access function
>tables exported by some other, non-Csound application hosting the UG. But I
>may be wrong about this...
FUNC's *are* an abstract interface, because the data itself is held in
a pointer to the storage, rather than within the FUNC itself. This
allows other applications to create the data, and then make it
available to Csound UG's by wrapping the data with a FUNC structure,
and putting into the list of tables. Thats the only piece of glue you
need.
There are several places in Quasimodo (e.g. my version of spliner,
that lets you draw your own function tables with the mouse) where I do
exactly this operation: generate the data, call for it to be wrapped
as a FunctionTable, and presto, FunctionTable::find (const char *name)
can find it.
>What do you think about this idea? Would you be open to using this
>JavaCsound kernel in Quasimodo, or merging the two kernels into one (as a
>shared library,
If it means moving away from C++, I'm not in favor of it. If it means
not using a formal grammar, I'm not in favor of it.
In addition, two things I forgot to mention in my quasimodo overview:
* Quasimodo can handle any number of quoted strings in the arguments to an
opcode. It is not limited to one-string-per-call the way that Csound is.
* Quasimodo uses names for function tables and instruments, not numbers,
though the names can be numeric if you so wish.
The first one of these has lots of implications for the parser and
compiler, and requires a dirty trick involving inner knowledge of IEEE
32 bit float format. The second one has less implications, but they
are still significant. I would not give up either of these features gladly.
>it can support any number of external interfaces, including,
>as I have said, Java, VST-2, Buzz machines, etc.).
This is true, and a very desirable goal. But I'm very familiar with
the benefits I've gained from using C++, and I am loathe to abandon
them for the sake of interoperability. Your advocacy on behalf of Java
over C++ is something I would echo on behalf of C++ over C for this
purpose. Managing the complexity of the internal compiler in C is not
impossible, but it is harder.
--p
ps. while i'm here:
* Quasimodo has an abstract interface for its internal DSP object. Porting
Quasimodo to a plugin card with some kind of DSP(s) on it is mostly
just a matter of reimplementing the DSP object. (this is currently an
exaggeration, but not by much)
Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa10375;
26 Jun 99 19:13 BST
Received: from [144.173.6.14] (helo=exeter.ac.uk)
by shaun.maths.bath.ac.uk with esmtp (Exim 2.12 #1)
id 10xwxA-0004R1-00
for jpff@maths.bath.ac.uk; Sat, 26 Jun 1999 19:13:24 +0100
Received: from noether [144.173.8.10] by hermes via SMTP (TAA07281); Sat, 26 Jun 1999 19:10:10 +0100 (BST)
Received: from exeter.ac.uk by maths.ex.ac.uk; Sat, 26 Jun 1999 19:09:58 +0100
Received: from root@smtp-out-001.wanadoo.fr [193.252.19.68] by hermes via ESMTP (TAA04279); Sat, 26 Jun 1999 19:09:57 +0100 (BST)
Received: from andira.wanadoo.fr [193.252.19.152] by wanadoo.fr
for
Paris Sat, 26 Jun 1999 20:09:18 +0200 (MET DST)
Received: from exbang.com (193.250.98.142) by andira.wanadoo.fr; 26 Jun 1999 20:09:36 +0200
Message-ID: <37752DCD.C4A7AF69@exbang.com>
Date: Sat, 26 Jun 1999 19:45:56 +0000
From: Michel Jullian
Reply-To: mj@exbang.com
X-Mailer: Mozilla 4.04 (Macintosh; I; PPC)
MIME-Version: 1.0
To: Csound List
CC: music-dsp@shoko.calarts.edu, JavaSound
Subject: Re: Proposal for a new version of Csound
References: <199906261643.MAA18507@renoir.op.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk
Paul Barton-Davis wrote:
>
> >Why not C++ ? Aren't UGs best modeled as objects (state + behavior) ?
>
> Indeed. Although actually, no, because of the speed penalty. This is
> one area where you don't want to mess around with too many object
> abstractions - its in the inner loop of Csound's execution.
You mean calling an object's method is actually longer than calling an
otherwise identical C function ? Why ? (sorry if that's obvious) Or is there
some silly redirection from the object to the class and from the class to the
corresponding function (I would have thought that would be solved at compile
time as a pointer to a function) ?
BTW, I agree it might be better for Michael's project to start from Quasimodo,
or for both of you to unite your efforts to make Quasimodo the next improved
version of Csound.
--
Greetings,
Michel
.........................................................................
Michel Jullian Directeur General email mj@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
.........................................................................
Received: from wallace.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa10425;
26 Jun 99 19:23 BST
Received: from [156.3.140.104] (helo=shoko.calarts.edu)
by wallace.maths.bath.ac.uk with esmtp (Exim 2.12 #1)
id 10xx70-0000Tj-00
for jpff@maths.bath.ac.uk; Sat, 26 Jun 1999 19:23:34 +0100
Received: (from majordom@localhost)
by shoko.calarts.edu (8.9.3/8.9.3) id LAA00520
for music-dsp-outgoing; Sat, 26 Jun 1999 11:10:02 -0700 (PDT)
X-Authentication-Warning: shoko.calarts.edu: majordom set sender to owner-music-dsp@shoko.calarts.edu using -f
Received: from wanadoo.fr (root@smtp-out-001.wanadoo.fr [193.252.19.68])
by shoko.calarts.edu (8.9.3/8.9.3) with ESMTP id LAA00516
for ; Sat, 26 Jun 1999 11:10:00 -0700 (PDT)
Received: from andira.wanadoo.fr [193.252.19.152] by wanadoo.fr
for
Paris Sat, 26 Jun 1999 20:09:18 +0200 (MET DST)
Received: from exbang.com (193.250.98.142) by andira.wanadoo.fr; 26 Jun 1999 20:09:36 +0200
Message-ID: <37752DCD.C4A7AF69@exbang.com>
Date: Sat, 26 Jun 1999 19:45:56 +0000
From: Michel Jullian
X-Mailer: Mozilla 4.04 (Macintosh; I; PPC)
MIME-Version: 1.0
To: Csound List
CC: music-dsp@shoko.calarts.edu, JavaSound
Subject: Re: Proposal for a new version of Csound
References: <199906261643.MAA18507@renoir.op.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-music-dsp@shoko.calarts.edu
Precedence: bulk
Reply-To: music-dsp@shoko.calarts.edu
Paul Barton-Davis wrote:
>
> >Why not C++ ? Aren't UGs best modeled as objects (state + behavior) ?
>
> Indeed. Although actually, no, because of the speed penalty. This is
> one area where you don't want to mess around with too many object
> abstractions - its in the inner loop of Csound's execution.
You mean calling an object's method is actually longer than calling an
otherwise identical C function ? Why ? (sorry if that's obvious) Or is there
some silly redirection from the object to the class and from the class to the
corresponding function (I would have thought that would be solved at compile
time as a pointer to a function) ?
BTW, I agree it might be better for Michael's project to start from Quasimodo,
or for both of you to unite your efforts to make Quasimodo the next improved
version of Csound.
--
Greetings,
Michel
.........................................................................
Michel Jullian Directeur General email mj@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
Received: from wallace.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa10443;
26 Jun 99 19:31 BST
Received: from [144.173.6.14] (helo=exeter.ac.uk)
by wallace.maths.bath.ac.uk with esmtp (Exim 2.12 #1)
id 10xxF2-0000Tr-00
for jpff@maths.bath.ac.uk; Sat, 26 Jun 1999 19:31:52 +0100
Received: from noether [144.173.8.10] by hermes via SMTP (TAA16798); Sat, 26 Jun 1999 19:28:30 +0100 (BST)
Received: from exeter.ac.uk by maths.ex.ac.uk; Sat, 26 Jun 1999 19:28:19 +0100
Received: from root@renoir.op.net [209.152.193.4] by hermes via ESMTP (TAA11636); Sat, 26 Jun 1999 19:28:17 +0100 (BST)
Received: from someip.ppp.op.net (d-bm3-0a.ppp.op.net [209.152.194.74]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id OAA23524; Sat, 26 Jun 1999 14:28:10 -0400 (EDT)
Message-Id: <199906261828.OAA23524@renoir.op.net>
To: mj@exbang.com
Cc: csound@maths.ex.ac.uk
Subject: Re: Proposal for a new version of Csound
In-reply-to: Your message of "Sat, 26 Jun 1999 19:45:56 -0000."
<37752DCD.C4A7AF69@exbang.com>
Date: Sat, 26 Jun 1999 14:34:53 -0400
From: Paul Barton-Davis
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk
>> Indeed. Although actually, no, because of the speed penalty. This is
>> one area where you don't want to mess around with too many object
>> abstractions - its in the inner loop of Csound's execution.
>
>You mean calling an object's method is actually longer than calling an
>otherwise identical C function ? Why ? (sorry if that's obvious) Or is there
>some silly redirection from the object to the class and from the class to the
>corresponding function (I would have thought that would be solved at compile
>time as a pointer to a function) ?
Function calls are just as fast, assuming that you were going to pass
in a ptr to a struct/object anyway. In rare cases, where the function
makes no reference to any of the object's members, pushing an extra
argument onto the stack before the call and popping it on the way out
is an unnecessary (very small) extra cost, but thats about it.
No, the increased overhead is more subtle, and has to do with
constructors and destructors. C++ does a lot more to enforce scope
restrictions than C, and this often/sometimes creates extra cost at
entry to and on departure from a function. In addition, if you're
using exceptions, that can cost extra as well since the compiler has
to set things up so that the stack can be unwound correctly.
In addition, if you're really going to use C++ effectively, as opposed
to just write C code and compile it with a C++ compiler, there are
typically costs associated with that as far as run time speed goes
i.e. there isn't an identical function.
If there *is* an identical function, and there are no constructors or
destructors, then its typically just as quick, and this is the
compromise I made in Quasimodo: I don't really do any C++ stuff with
the opcode arguments once they get inside the opcode function, so the
opcodes still look like regular C (with three exceptions, below). But
when we set up the voice, we use C++ extensively to set up the opcode
arguments.
The exceptions are (1) error reporting and (2) dynamic memory
allocation aka "auxalloc() (both of these use methods of the opcode
argument and AUXCH respectively) and lastly (3) pointers to reference
counted objects like function tables, which do require a
compiler-generated constructor call.
--p
Received: from wallace.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa10929;
27 Jun 99 1:31 BST
Received: from [144.173.6.14] (helo=exeter.ac.uk)
by wallace.maths.bath.ac.uk with esmtp (Exim 2.12 #1)
id 10y2rI-0000Zg-00
for jpff@maths.bath.ac.uk; Sun, 27 Jun 1999 01:31:44 +0100
Received: from noether [144.173.8.10] by hermes via SMTP (BAA07704); Sun, 27 Jun 1999 01:25:35 +0100 (BST)
Received: from exeter.ac.uk by maths.ex.ac.uk; Sun, 27 Jun 1999 01:25:23 +0100
Received: from rothko.bestweb.net [209.94.100.160] by hermes via ESMTP (BAA06435); Sun, 27 Jun 1999 01:25:22 +0100 (BST)
Received: from goodguy (dialin-176.poughkeepsie.bestweb.net [216.179.13.74])
by rothko.bestweb.net (8.9.1a/8.9.0) with SMTP id UAA18041;
Sat, 26 Jun 1999 20:23:03 -0400 (EDT)
Message-ID: <37754F82.17207BAB@westnet.com>
Date: Sat, 26 Jun 1999 22:09:06 +0000
From: Larry Troxler
X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.31 i586)
MIME-Version: 1.0
To: Gabriel Maldonado
CC: Csound Mailing List
Subject: Re: RT MIDI In -> both Csound and MIDI file?
References: <199906260343.XAA19678@renoir.op.net> <37745F2F.4ECDC14B@ulster.net> <37748F1C.5EAF6AB3@agora.stm.it>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk
Gabriel Maldonado wrote:
>
> New opcodes of DirectCsound 'foutk', 'fouti', 'fiopen', 'foutir', 'fin',
> 'fink' and 'fini' can do this task, if properly used, even without
> recording a MIDI file. Maybe John Fitch will decide to port them in
> standard version, one day (and I hope it):
>
I think I'll find 'foutir' to be fine for "fout"ing my file ...
The IDE disk accesses on my old P100 machine often cause droputs,
though, so I'm thinking that if this proves to be a problem, I could
hack the code to write everything to a pre-allocated RAM buffer, and
then write to a file after the perf is over.
For control signals, of course I guess I would use foutk, for example,
instead of foutir.
(BTW anyone ever figure out how to tune the disk-flush deamon to result
in minimum amounts of long kernel interruptions?)
As far as porting the stuff to the standard version, have you people
been sumbmitting patches for the standard version, and John Fitch
doesn't like them? I can't imagine why these opcodes you mention
shouldn't be in the canonical sources (or the real-time priority for
that matter). John, is there a reason, or is it just that nobody has
taken the time to submit a patch against the canonical sources?
Larry
Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa11675;
27 Jun 99 10:10 BST
Received: from [144.173.6.14] (helo=exeter.ac.uk)
by shaun.maths.bath.ac.uk with esmtp (Exim 2.12 #1)
id 10yAwp-0004hn-00
for jpff@maths.bath.ac.uk; Sun, 27 Jun 1999 10:09:59 +0100
Received: from noether [144.173.8.10] by hermes via SMTP (KAA16133); Sun, 27 Jun 1999 10:05:12 +0100 (BST)
Received: from exeter.ac.uk by maths.ex.ac.uk; Sun, 27 Jun 1999 10:04:58 +0100
Received: from root@smtp-out-006.wanadoo.fr [193.252.19.98] by hermes via ESMTP (KAA01355); Sun, 27 Jun 1999 10:04:57 +0100 (BST)
Received: from amyris.wanadoo.fr [193.252.19.150] by wanadoo.fr
for
Paris Sun, 27 Jun 1999 11:04:56 +0200 (MET DST)
Received: from exbang.com (193.250.98.202) by amyris.wanadoo.fr; 27 Jun 1999 11:04:26 +0200
Message-ID: <37753A66.C02DADED@exbang.com>
Date: Sat, 26 Jun 1999 20:39:44 +0000
From: Michel Jullian
Reply-To: mj@exbang.com
X-Mailer: Mozilla 4.04 (Macintosh; I; PPC)
MIME-Version: 1.0
To: csound@maths.ex.ac.uk
CC: music-dsp list
Subject: Re: Proposal for a new version of Csound
References: <199906261722.NAA20401@renoir.op.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk
Paul Barton-Davis wrote:
>
> >What do you think about this idea? Would you be open to using this
> >JavaCsound kernel in Quasimodo, or merging the two kernels into one (as a
> >shared library,
>
> If it means moving away from C++, I'm not in favor of it. If it means
> not using a formal grammar, I'm not in favor of it.
Well, what do you think Michael ? Might be worth considering C++ :-)
--
Greetings,
Michel
.........................................................................
Michel Jullian Directeur General email mj@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
.........................................................................
Received: from wallace.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa11687;
27 Jun 99 10:17 BST
Received: from [156.3.140.104] (helo=shoko.calarts.edu)
by wallace.maths.bath.ac.uk with esmtp (Exim 2.12 #1)
id 10yB3u-0000lu-00
for jpff@maths.bath.ac.uk; Sun, 27 Jun 1999 10:17:18 +0100
Received: (from majordom@localhost)
by shoko.calarts.edu (8.9.3/8.9.3) id CAA09997
for music-dsp-outgoing; Sun, 27 Jun 1999 02:05:02 -0700 (PDT)
X-Authentication-Warning: shoko.calarts.edu: majordom set sender to owner-music-dsp@shoko.calarts.edu using -f
Received: from wanadoo.fr (root@smtp-out-006.wanadoo.fr [193.252.19.98])
by shoko.calarts.edu (8.9.3/8.9.3) with ESMTP id CAA09993
for ; Sun, 27 Jun 1999 02:05:00 -0700 (PDT)
Received: from amyris.wanadoo.fr [193.252.19.150] by wanadoo.fr
for
Paris Sun, 27 Jun 1999 11:04:56 +0200 (MET DST)
Received: from exbang.com (193.250.98.202) by amyris.wanadoo.fr; 27 Jun 1999 11:04:26 +0200
Message-ID: <37753A66.C02DADED@exbang.com>
Date: Sat, 26 Jun 1999 20:39:44 +0000
From: Michel Jullian
X-Mailer: Mozilla 4.04 (Macintosh; I; PPC)
MIME-Version: 1.0
To: csound@maths.ex.ac.uk
CC: music-dsp list
Subject: Re: Proposal for a new version of Csound
References: <199906261722.NAA20401@renoir.op.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-music-dsp@shoko.calarts.edu
Precedence: bulk
Reply-To: music-dsp@shoko.calarts.edu
Paul Barton-Davis wrote:
>
> >What do you think about this idea? Would you be open to using this
> >JavaCsound kernel in Quasimodo, or merging the two kernels into one (as a
> >shared library,
>
> If it means moving away from C++, I'm not in favor of it. If it means
> not using a formal grammar, I'm not in favor of it.
Well, what do you think Michael ? Might be worth considering C++ :-)
--
Greetings,
Michel
.........................................................................
Michel Jullian Directeur General email mj@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
Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa11773;
27 Jun 99 11:30 BST
Received: from [144.173.6.14] (helo=exeter.ac.uk)
by shaun.maths.bath.ac.uk with esmtp (Exim 2.12 #1)
id 10yCCh-0004iX-00
for jpff@maths.bath.ac.uk; Sun, 27 Jun 1999 11:30:27 +0100
Received: from noether [144.173.8.10] by hermes via SMTP (LAA04100); Sun, 27 Jun 1999 11:24:41 +0100 (BST)
Received: from exeter.ac.uk by maths.ex.ac.uk; Sun, 27 Jun 1999 11:24:29 +0100
Received: from [199.203.20.14] by hermes via ESMTP (LAA05994); Sun, 27 Jun 1999 11:24:27 +0100 (BST)
Received: by SHORE with Internet Mail Service (5.5.2448.0)
id ; Sun, 27 Jun 1999 13:23:24 +0200
Message-ID:
From: Oded Streigold
To: "'csound@maths.ex.ac.uk'"
Subject: Initilize variable?
Date: Sun, 27 Jun 1999 13:23:23 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk
Hi,
I'm a CSound newbe, lurking in here for a while.
Is it possible to initilize a-rate variables at init time to a certain value
(e.g.: a1 = 3 ) , but that at performance time it's value would change in
time like a normal a-rate variable?
Thanks,
Oded Streigold.
benjic@bigfoot.com
Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa11824;
27 Jun 99 12:19 BST
Received: from [144.173.6.14] (helo=exeter.ac.uk)
by shaun.maths.bath.ac.uk with esmtp (Exim 2.12 #1)
id 10yCxy-0004iq-00
for jpff@maths.bath.ac.uk; Sun, 27 Jun 1999 12:19:18 +0100
Received: from noether [144.173.8.10] by hermes via SMTP (MAA03836); Sun, 27 Jun 1999 12:13:52 +0100 (BST)
Received: from exeter.ac.uk by maths.ex.ac.uk; Sun, 27 Jun 1999 12:13:40 +0100
Received: from grynet.passagen.se [195.163.107.36] by hermes via ESMTP (MAA08565); Sun, 27 Jun 1999 12:13:39 +0100 (BST)
Received: from dumburk (z15-4-186.sbbs2.net [212.112.4.186])
by grynet.passagen.se (8.8.6/8.8.6) with SMTP id NAA22077
for ; Sun, 27 Jun 1999 13:13:37 +0200 (MDT)
Message-ID: <37760854.7F72@hem.passagen.se>
Date: Sun, 27 Jun 1999 13:17:40 +0200
From: rasmus ekman
X-Mailer: Mozilla 3.04 (Win95; I)
MIME-Version: 1.0
To: Csound list
Subject: Re: Initilize variable?
References:
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk
Oded Streigold wrote:
>
> Is it possible to initilize a-rate variables at init time
Use init, like
a1 init 3
re |