| Greetings Csounders,
Here is an opcode which starts new instrument events from orchestra
at k-rate. Events are started every time a triggering signal is non-zero.
Event generation may be limited in two ways: by setting a minimum time
interval between generated events, or by specifying a maximum number
of simultaneous instruments instances. Events may also be deferred.
This opcode may be useful for things like generating strumming gestures,
or for some types of algorithmic composition.
Below are the code changes and two new files (triginstr.h and triginstr.c).
Documentation of the triginstr opcode follows at the end of this post.
Regards,
re
========================
CODE CHANGES
(A bit more to do than for other opcodes: Due to the way Csound handles
instrument event turnoff, this ugen requires some changes to core
stuff like OPARMS, playevents() and kperf() - we have to add a new type
of realtime event.)
In Entry.c, declare in the appropriate places near the top:
------------------------
#include "triginstr.h"
void triginset(TRIGINSTR *p), ktriginstr(TRIGINSTR *p);
------------------------
In Entry.c, anywhere in opcodlst[]:
------------------------
{ "triginstr", S(TRIGINSTR),3, "", "kkkkkz",triginset, ktriginstr, NULL },
========================
In Cs.h, in struct OPARMS, eg line 82 (new line marked >>>):
------------------------
int usingcscore, Linein, Midiin, FMidiin;
>>> int OrcEvts; /* - for triginstr (re Aug 1999) */
int RTevents, ksensing;
========================
Insert.c, among declares, eg line 31:
------------------------
int sensOrcEvent(void); /* For triginstr (re Aug 1999) */
------------------------
Insert.c, function kperf(), on lines 563 - 570:
Change the line marked ">>>", and insert the line marked "++>>":
------------------------
if (O.RTevents) {
if (O.Midiin && (sensType = sensMidi()) /* if MIDI note message */
|| O.FMidiin && kcounter >= FMidiNxtk
&& (sensType = sensFMidi())
>>> || O.Linein && (sensType = sensLine()) /* or Linein event */
++>> || O.OrcEvts && (sensType = sensOrcEvent())) /* or triginstr event (re Aug 1999) */
return(kreq - kcnt); /* do early return */
}
========================
Musmon.c, among header includes, eg line 6,
------------------------
#include "triginstr.h"
------------------------
Musmon.c, function playevents(), at label mtest, line 515:
Replace the lines
mtest:
if (sensType >= 2) { /* Midievent: */
with the following:
------------------------
mtest:
/* Old test: */
/* if (sensType >= 2) { /* Midievent: */
/* New version (re Aug 1999): */
if (sensType == 2 || sensType == 3) { /* Midievent: */
------------------------
NOTE: Somebody may feel queasy about changing the test here.
The present test captures all sensType values above 2. This is unnecessary,
as only 2 and 3 are ever used. This is quite easily verifiable: sensType
is set by calling sensMidi(), sensFMidi(), or sensLine(), as seen in the
code snippet from Insert.c above.
These functions only use direct return values 1 (sensLine), 2 (sensMidi)
or 3 (sensFMidi) - or zero for no event.
The dark horse is MacSensMidi(), which is called from sensMidi()
(#ifdef macintosh), but not provided with the Bath source distribution.
This function is however in the Mills Perf code distribution, and
returns 2 (or zero) as expected.
========================
Musmon.c, function playevents(), around line 470:
At the lines
if (sensType == 1) { /* for Linein, */
e = Linevtblk; /* get its evtblk */
e->p[2] = curp2; /* & insert curp2 */
}
>>> insert new lines here
if (!kdone) /* if null duration, */
goto mtest; /* chk for midi on-off */
Insert the following case (now the old lines are marked with >>>):
------------------------
>>> if (sensType == 1) { /* for Linein, */
>>> e = Linevtblk; /* get its evtblk */
>>> e->p[2] = curp2; /* & insert curp2 */
>>> }
else if(sensType == 4) { /* Realtime orc event (re Aug 1999) */
EVTNODE *evtlist = OrcTrigEvts.nxtevt;
while (evtlist && evtlist->kstart <= kcounter) {
int insno = evtlist->insno;
e = &evtlist->evt;
evtlist = OrcTrigEvts.nxtevt = evtlist->nxtevt;
/* If several events pending we must insert all but one
- code copied from switch(e->opcod) case 'i' below */
if(evtlist && evtlist->kstart <= kcounter) {
if (O.Beatmode && e->p3orig >= 0.)
e->p[3] = e->p3orig * betsiz;
if (n = insert(insno, e)) { /* alloc,init,activate */
printf("\t\t T%7.3f",curp2);
printf("triginstr note deleted. i%d had %d init errors\n",
insno, n);
perferrcnt++;
}
}
}
if(OrcTrigEvts.nxtevt == NULL) O.OrcEvts = 0;
}
>>> if (!kdone) /* if null duration, */
>>> goto mtest; /* chk for midi on-off */
========================
NEW FILES:
triginstr.h:
------------------------
/*****************************************************************/
/* triginstr - Start instrument events at k-rate from orchestra. */
/* August 1999 by rasmus ekman. */
/*****************************************************************/
typedef struct {
OPDS h;
FLOAT *trigger, *mintime, *maxinst;
FLOAT *args[PMAX+1];
FLOAT prvmintim;
long timrem, prvktim, kadjust;
} TRIGINSTR;
typedef struct eventnode {
EVTBLK evt; /* Must be first in struct so it can be typecast & freed */
struct eventnode *nxtevt;
int kstart, insno;
} EVTNODE;
extern EVTNODE OrcTrigEvts;
extern int sensOrcEvent(void);
========================
triginstr.c:
------------------------
/******************************************************************************/
/* triginstr - Ignite instrument events at k-rate from orchestra. */
/* August 1999 by rasmus ekman. */
/* Changes made also to Cs.h, Musmon.c and Insert.c; look for "(re Aug 1999)" */
/******************************************************************************/
#include "cs.h"
#include "triginstr.h"
/* Some global declarations we need */
extern INSTRTXT **instrtxtp; /* List of instrument declarations (orchestra) */
extern INSDS actanchor; /* Chain of active instrument instances */
extern void infoff(FLOAT p1); /* Turn off an indef copy of instr p1 */
extern long kcounter; /* Count of k-periods throughout performance */
extern int sensType; /* 0=score evt, 1=Linein, 2/3=midi, 4=triginstr */
#define FZERO (0.0f) /* (Shouldn't there be global decl's for these?) */
#define FONE (1.0f)
EVTNODE OrcTrigEvts; /* List of started events, used in playevents() (Musmon.c) */
/* Called from kperf() to see if any event to turn on */
int sensOrcEvent(void) {
if(OrcTrigEvts.nxtevt && OrcTrigEvts.nxtevt->kstart <= kcounter)
return(4); /* sensType value (0=score,1=line,2/3=midi) */
else return(0);
}
void ktriginstr(TRIGINSTR *p);
void triginset(TRIGINSTR *p) {
p->prvmintim = *p->mintime;
p->timrem = 0;
/* An instrument is initialised before kcounter is incremented for
this k-cycle, and begins playing after kcounter++.
Therefore, if we should start something at the very first k-cycle of
performance, we must thus do it now, lest it be one k-cycle late.
But in ktriginstr() we'll need to use kcounter-1 to set the start time
of new events. So add a separate variable for the kcounter offset (-1). */
if(kcounter == 0 && *p->trigger > FZERO && *p->args[1] <= FZERO) {
p->kadjust = 0; /* No kcounter offset at this time */
ktriginstr(p);
}
p->kadjust = -1; /* Set kcounter offset for perf-time */
return;
}
void ktriginstr(TRIGINSTR *p) { /* k-rate event generator */
int i, absinsno, argnum;
FLOAT insno, starttime;
EVTNODE *evtlist, *newnode;
EVTBLK *newevt;
if(*p->trigger == FZERO) /* Only do something if triggered */
return;
/* Get absolute instr num */
insno = *p->args[0];
absinsno = abs((int)insno);
/* Check that instrument is defined */
if(absinsno > maxinsno || instrtxtp[absinsno] == NULL) {
printf("triginstr ignored. Instrument %d undefined\n", absinsno);
perferrcnt++;
return;
}
/* On neg instrnum, turn off a held copy.
(Regardless of mintime/maxinst) */
if(insno < FZERO) {
infoff(-insno);
return;
}
/* Check if mintime has changed */
if(p->prvmintim != *p->mintime) {
long timrem = (int)(*p->mintime * ekr + 0.5f);
if(timrem > 0) {
/* Adjust countdown for new mintime */
p->timrem += timrem - p->prvktim;
p->prvktim = timrem;
} else timrem = 0;
p->prvmintim = *p->mintime;
}
/* Check for rate limit on event generation and count down */
if(*p->mintime > FZERO && --p->timrem > 0)
return;
/* See if there are too many instances already */
if(*p->maxinst >= FONE) {
INSDS *ip;
int numinst = 0;
/* Count active instr instances */
ip = &actanchor;
while ((ip = ip->nxtact) != NULL)
if(ip->insno == absinsno) numinst++;
if(numinst >= (int)*p->maxinst)
return;
}
/* Create the new event */
newnode = (EVTNODE *) mmalloc((long)sizeof(EVTNODE));
newevt = &newnode->evt;
newevt->opcod = 'i';
/* Set start time from kwhen */
starttime = *p->args[1];
if(starttime < FZERO) {
starttime = FZERO;
warning("triginstr warning: negative kwhen reset to zero");
}
/* Add current time (see note about kadjust in triginset() above) */
starttime += (FLOAT)(kcounter + p->kadjust) * onedkr;
newnode->kstart = (long)(starttime * ekr + 0.5f);
newevt->p2orig = starttime;
newevt->p3orig = *p->args[2];
/* Copy all arguments to the new event */
newevt->pcnt = argnum = p->INOCOUNT-3;
for(i = 0; i < argnum; i++)
newevt->p[i+1] = *p->args[i];
newevt->p[2] = starttime; /* Set actual start time in p2 */
newnode->insno = absinsno;
/* Set event activation time in k-cycles */
newnode->kstart = (long)(starttime * ekr + 0.5f);
/* Insert eventnode in list of generated events */
evtlist = &OrcTrigEvts;
while (evtlist->nxtevt) {
if(newnode->kstart < evtlist->nxtevt->kstart) break;
evtlist = evtlist->nxtevt;
}
newnode->nxtevt = evtlist->nxtevt;
evtlist->nxtevt = newnode;
O.RTevents = 1; /* Make sure kperf() looks for RT events */
O.ksensing = 1;
O.OrcEvts = 1; /* - of the appropriate type */
/* Reset min pause counter */
if(*p->mintime > FZERO)
p->timrem = (long)(*p->mintime * ekr + 0.5f);
else p->timrem = 0;
return;
}
========================
DOCUMENTATION:
------------------------
Ignite Instrument Events
triginstr ktrigger, kmintime, kmaxinst, kinstr, kwhen, kdur[, kp4, ... kpN]
Generate new instrument events from orchestra.
This opcode may be useful eg for certain kinds of algorithmic composition.
ARGUMENTS
ktrigger - when non-zero, signal that an instrument instance
should be started.
kmintime - controls the minimal time which is to elapse between
generated events, in seconds. If kmintime <= 0, no time limit is
used. If the kinstr instrument number is negative (to turn off
an instrument), this test is bypassed.
kmaxinst - ceiling for the number of simultaneous instances of
instrument kinstr. If number of existant instances of kinstr
is >= kmaxinst, no event is generated. If kmaxinst is <= 0, it is
not used to limit event generation. If the kinstr instrument
number is negative (to turn off an instrument), this test is
bypassed.
kinstr, kwhen, kdur, ... - same arguments as in score i statements.
The kwhen start time (p2) is measured from the time of the triggering
event, and must be a positive value (or zero).
If an event is deferred by a p2 offset value, the instrument will
not be initialized until the actual time when it should start performing.
PERFORMANCE
triginstr adds a new instrument event to the Csound performance
each time the krate value ktrigger is non-zero. Event generation
may be limited by the kmintime and kmaxinst arguments. The instrument
will be initialized at the time when it actually begins playing.
The arguments for the generated instrument event are the same as
in a score i-statement. The kwhen time (p2) is measured from the time
of the triggering event. If kdur (p3) is zero the instrument will
only do an initialization pass without performance. A negative kdur
value will initiate a held note (see also ihold and i-statements).
Note that while delayed events are pending, and no events are
playing, the performance must be kept going, or Csound will quit.
To guarantee continued performance, the f0 statement may be used
in score (same as eg when playing midi files, or padding score
sections with silence).
EXAMPLES
The offset value is useful for triggering multiple instruments
in fixed relations. Here, two alternating metronomes:
instr 5 ; tick-tock, tick-tock
iBPM init p4
; Instr's 6 and 7 could be eg simple sample players
triginstr 1, 60/iBPM, 0, 6, 0, .5
triginstr 1, 60/iBPM, 0, 7, 30/iBPM, .5
endin
;Score
; Generate events at 150 BPM for 10 secs
i1 0 10 150
This example will create a strumming gesture of p5 notes in p6 seconds
instr 10 ; Strummer
; Pass some values to the strummed instr
koct init p4
iamp init 12000
; Init strum delay so p5 events start in (roughly) p6 seconds
iNumEvts init p5
knum init 0
iDelBase init (p6 / sqrt(iNumEvts)) * 1.7
kdel init 0
; Generate p5 events in the first p5 k-cycles
knum = knum + 1
ktrig = (knum <= iNumEvts ? 1 : 0)
; Strum instr 11, passing pitch and "intended pitch" to pluck
; for some spectral variation. (knum is also passed for diagnostics)
triginstr ktrig, 0, 0, 11, kdel, .5, iamp, cpspch(koct), cpspch(koct) * (knum+2), knum
; Increase delay for next events
kdel = kdel + iDelBase / (knum+1)
; and play a chord (just to do something)
koct = koct +.03
; Don't need this instr after the evts generated, so turn off
if knum < iNumEvts kgoto continue
turnoff
continue:
endin
instr 11 ; Strummed instrument
; print p2, pchoct(octcps(p5)), p6, p7
kamp linseg p4, p3-.1, p4, .1, 0
ar pluck kamp, p5, p6, 0, 1
out ar
endin
; Score
i10 0 .1 6.10 6 .6
i10 1.5 .3 7.00 6 .7
i10 3 .3 6.03 11 1.5
f0 5
e
This example uses xyin to provide gestural control of event generation:
; Orchestra
sr = 22050
kr = 882
ksmps = 25
nchnls = 2
instr 9 ; Generate 1 - 50 events per sec (max 20 simultaneous)
kX, kY xyin .03, .02, 1, 0, 3000, 1, 100
triginstr 1, kX/2, 20, 2, 0, .7, kY, kY/(kX*.5)
endin
instr 12
kamp linseg 15000, p3-.05, 15000, .05, 0
kcps line p4, p3, p5
ar pluck kamp, p4, p5, 0, 1 pan
; Random stereo distribution
a1, a2 locsig ar, rnd(360), 1, 0
outs a1, a2
endin
; Score
f1 0 8192 10 1 ; Sine
i9 0 15
e
Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa28003;
2 Sep 99 15:46 BST
Received: from [144.173.6.14] (helo=exeter.ac.uk)
by shaun.maths.bath.ac.uk with esmtp (Exim 2.12 #1)
id 11MY8R-000452-00
for jpff@maths.bath.ac.uk; Thu, 2 Sep 1999 15:46:43 +0100
Received: from noether [144.173.8.10] by hermes via SMTP (PAA08132); Thu, 2 Sep 1999 15:42:48 +0100 (BST)
Received: from exeter.ac.uk by maths.ex.ac.uk; Thu, 2 Sep 1999 15:42:35 +0100
Received: from exim@wallace.maths.bath.ac.uk [138.38.100.104] by hermes via ESMTP (PAA08117); Thu, 2 Sep 1999 15:42:34 +0100 (BST)
Received: from [138.38.97.36] (helo=maths.Bath.AC.UK ident=mmdf)
by wallace.maths.bath.ac.uk with smtp (Exim 2.12 #1)
id 11MWxI-0004JZ-00
for csound@maths.ex.ac.uk; Thu, 2 Sep 1999 14:31:08 +0100
From: jpff@maths.bath.ac.uk
To: csound@maths.ex.ac.uk
Subject: [mpoirier@virtu.sar.usf.edu: Re: Looking for drums]
Date: Thu, 2 Sep 99 15:42:31 BST
Source-Info: From (or Sender) name not authenticated.
Message-Id:
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk
Date: Wed, 01 Sep 1999 15:06:12 -0400
From: Marc 3 Poirier
Sorry to be so completely un-Csoundy, but all you folks trying to make
analogue-synth-like drum sounds should really be using the program Stomper,
available for free here:
http://www.lysator.liu.se/~zap/stomper.html
It's a program designed specifically & solely for doing what you folks are
wanting to do. It's incredibly easy to figure out & use & you'll be
getting the results you want about a billion times faster than by
fine-tuning ORCs & SCOs.
Marc Poirier
Received: from wallace.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa28567;
2 Sep 99 19:08 BST
Received: from [144.173.6.14] (helo=exeter.ac.uk)
by wallace.maths.bath.ac.uk with esmtp (Exim 2.12 #1)
id 11MaAt-0004UL-00
for jpff@maths.bath.ac.uk; Thu, 2 Sep 1999 17:57:23 +0100
Received: from noether [144.173.8.10] by hermes via SMTP (TAA15572); Thu, 2 Sep 1999 19:04:19 +0100 (BST)
Received: from exeter.ac.uk by maths.ex.ac.uk; Thu, 2 Sep 1999 19:04:07 +0100
Received: from frad.onet.pl [194.204.188.215] by hermes via ESMTP (TAA13304); Thu, 2 Sep 1999 19:04:06 +0100 (BST)
Received: from priv2.onet.pl ([194.204.188.142]:13410 "EHLO priv2.onet.pl")
by frad.onet.pl with ESMTP id ;
Thu, 2 Sep 1999 20:03:53 +0200
Received: from [155.158.221.20] ([155.158.221.20]:2820 "HELO jaro" ident: "NO-IDENT-SERVICE[2]") by priv2.onet.pl with SMTP id <1295708-16366>; Thu, 2 Sep 1999 16:43:16 +0200
Message-ID: <000e01bef555$b6af0020$0100a8c0@jaro>
From: mamczar
To: csound@maths.ex.ac.uk
MMDF-Warning: Parse error in original version of preceding line at UK.AC.Bath.maths.omphalos
Subject: Network sound
Date: Thu, 2 Sep 1999 17:13:28 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_000B_01BEF566.7955FBA0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2417.2000
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk
This is a multi-part message in MIME format.
------=_NextPart_000_000B_01BEF566.7955FBA0
Content-Type: text/plain;
charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
Hi.
Sorry, a little off topic question...
Does anybody know a tool that can send audio data stream from one =
computer to another via network (a... really from one sound card to =
another)??
Thanks for any support.
J.Mamczarski
------=_NextPart_000_000B_01BEF566.7955FBA0
Content-Type: text/html;
charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
Hi.
Sorry, a little off topic=20
question...
Does anybody know a tool that can =
send audio=20
data stream from one computer to another via network (a... really from =
one sound=20
card to another)??
Thanks for any =
support.
J.Mamczarski
------=_NextPart_000_000B_01BEF566.7955FBA0--
Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa28599;
2 Sep 99 19:20 BST
Received: from [144.173.6.14] (helo=exeter.ac.uk)
by shaun.maths.bath.ac.uk with esmtp (Exim 2.12 #1)
id 11MbTJ-0004BQ-00
for jpff@maths.bath.ac.uk; Thu, 2 Sep 1999 19:20:29 +0100
Received: from noether [144.173.8.10] by hermes via SMTP (TAA13649); Thu, 2 Sep 1999 19:17:15 +0100 (BST)
Received: from exeter.ac.uk by maths.ex.ac.uk; Thu, 2 Sep 1999 19:17:05 +0100
Received: from sparticus.bright.net [205.212.123.5] by hermes via ESMTP (TAA16683); Thu, 2 Sep 1999 19:17:04 +0100 (BST)
Received: from bright.net (find-cas2-cs-38.dial.bright.net [209.143.26.192])
by sparticus.bright.net (8.9.3/8.9.3 ComNet Build) with ESMTP id OAA29630;
Thu, 2 Sep 1999 14:16:40 -0400 (EDT)
Message-ID: <37CEC520.7F507457@bright.net>
Date: Thu, 02 Sep 1999 14:42:40 -0400
From: Dave Phillips
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: mamczar
CC: csound@maths.ex.ac.uk
Subject: Re: Network sound
References: <000e01bef555$b6af0020$0100a8c0@jaro>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk
mamczar wrote:
> Sorry, a little off topic question...
> Does anybody know a tool that can send audio data stream from one
> computer to another via network (a... really from one sound card to
> another)??
If you're running UNIX or Linux you might want to look here:
http://www.bright.net/~dlphilp/linuxsound/netaudio.html
== Dave Phillips
http://www.bright.net/~dlphilp/index.html
http://sunsite.univie.ac.at/Linux-soundapp/linux_soundapps.html
Received: from wallace.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa28627;
2 Sep 99 19:34 BST
Received: from [144.173.6.14] (helo=exeter.ac.uk)
by wallace.maths.bath.ac.uk with esmtp (Exim 2.12 #1)
id 11Maa9-0004Uf-00
for jpff@maths.bath.ac.uk; Thu, 2 Sep 1999 18:23:29 +0100
Received: from noether [144.173.8.10] by hermes via SMTP (TAA15044); Thu, 2 Sep 1999 19:32:19 +0100 (BST)
Received: from exeter.ac.uk by maths.ex.ac.uk; Thu, 2 Sep 1999 19:32:08 +0100
Received: from saba.wwa.com [198.49.174.36] by hermes via ESMTP (TAA14978); Thu, 2 Sep 1999 19:32:07 +0100 (BST)
Received: from [157.238.67.158] (157-238-67-158.il.verio.net [157.238.67.158])
by saba.wwa.com (8.9.0/8.9.0) with SMTP id NAA11544
for ; Thu, 2 Sep 1999 13:31:50 -0500 (CDT)
Message-Id: <199909021831.NAA11544@saba.wwa.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 2 Sep 1999 13:37:01 -0600
To: csound@maths.ex.ac.uk
From: "17.hzV.tRL.478"
Subject: Re: Network sound
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk
>Hi.
>Sorry, a little off topic question...
>Does anybody know a tool that can send audio data stream from one computer to
>another via network (a... really from one sound card to another)??
>Thanks for any support.
>J.Mamczarski
ueb zrvr
pd
max
qt
audiomaze = zndz snd data +? odr kntrl data +?
k!berzveta = dze juzt a tool falaz!. = zndz kntrl data
Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa28642;
2 Sep 99 19:38 BST
Received: from [144.173.6.14] (helo=exeter.ac.uk)
by shaun.maths.bath.ac.uk with esmtp (Exim 2.12 #1)
id 11Mbkf-0004Bo-00
for jpff@maths.bath.ac.uk; Thu, 2 Sep 1999 19:38:25 +0100
Received: from noether [144.173.8.10] by hermes via SMTP (TAA03347); Thu, 2 Sep 1999 19:35:16 +0100 (BST)
Received: from exeter.ac.uk by maths.ex.ac.uk; Thu, 2 Sep 1999 19:35:05 +0100
Received: from saba.wwa.com [198.49.174.36] by hermes via ESMTP (TAA13800); Thu, 2 Sep 1999 19:35:04 +0100 (BST)
Received: from [157.238.67.158] (157-238-67-158.il.verio.net [157.238.67.158])
by saba.wwa.com (8.9.0/8.9.0) with SMTP id NAA12908
for ; Thu, 2 Sep 1999 13:35:03 -0500 (CDT)
Message-Id: <199909021835.NAA12908@saba.wwa.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 2 Sep 1999 13:40:13 -0600
To: csound@maths.ex.ac.uk
From: "17.hzV.tRL.478"
Subject: Re: Network sound
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk
http://web.access.net.au/~jreich/audiomaze.html
>any new audio-buffer data coming in, after it receives a new one, to prevent
>the >client from flooding the tcp buffer. However I dont want this block to
>act >on other
>nodes, so a client can stop sending audio data but still continue to send
>>controller data.
zndz aud!o data
Received: from wallace.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa28969;
2 Sep 99 22:04 BST
Received: from [144.173.6.14] (helo=exeter.ac.uk)
by wallace.maths.bath.ac.uk with esmtp (Exim 2.12 #1)
id 11Mcus-0004Yo-00
for jpff@maths.bath.ac.uk; Thu, 2 Sep 1999 20:53:02 +0100
Received: from noether [144.173.8.10] by hermes via SMTP (WAA14480); Thu, 2 Sep 1999 22:01:13 +0100 (BST)
Received: from exeter.ac.uk by maths.ex.ac.uk; Thu, 2 Sep 1999 22:01:02 +0100
Received: from frad.onet.pl [194.204.188.215] by hermes via ESMTP (WAA08402); Thu, 2 Sep 1999 22:01:01 +0100 (BST)
Received: from priv2.onet.pl ([194.204.188.142]:19778 "EHLO priv2.onet.pl")
by frad.onet.pl with ESMTP id ;
Thu, 2 Sep 1999 23:00:46 +0200
Received: from [155.158.221.20] ([155.158.221.20]:10756 "HELO jaro" ident: "NO-IDENT-SERVICE[2]") by priv2.onet.pl with SMTP id <1282216-16364>; Thu, 2 Sep 1999 23:00:00 +0200
Message-ID: <000701bef58a$5b1be7c0$0100a8c0@jaro>
From: mamczar
To: Dave Phillips
Cc: csound@maths.ex.ac.uk
MMDF-Warning: Parse error in original version of preceding line at UK.AC.Bath.maths.omphalos
References: <000e01bef555$b6af0020$0100a8c0@jaro> <37CEC520.7F507457@bright.net>
Subject: Odp: Network sound
Date: Thu, 2 Sep 1999 23:30:16 +0200
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 5.00.2417.2000
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk
Thanx all...
----- Original Message -----
From: Dave Phillips
To: mamczar
Cc:
Sent: Thursday, September 02, 1999 8:42 PM
Subject: Re: Network sound
> mamczar wrote:
>
> > Sorry, a little off topic question...
> > Does anybody know a tool that can send audio data stream from one
> > computer to another via network (a... really from one sound card to
> > another)??
>
> If you're running UNIX or Linux you might want to look here:
>
> http://www.bright.net/~dlphilp/linuxsound/netaudio.html
>
> == Dave Phillips
>
> http://www.bright.net/~dlphilp/index.html
> http://sunsite.univie.ac.at/Linux-soundapp/linux_soundapps.html
>
Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa29112;
2 Sep 99 23:44 BST
Received: from [195.163.107.36] (helo=grynet.passagen.se)
by shaun.maths.bath.ac.uk with esmtp (Exim 2.12 #1)
id 11Mfb1-0004Fd-00
for jpff@maths.bath.ac.uk; Thu, 2 Sep 1999 23:44:43 +0100
Received: from hem.passagen.se (z4-1-212.sbbs2.net [212.112.1.212])
by grynet.passagen.se (8.8.6/8.8.6) with ESMTP id AAA02168;
Fri, 3 Sep 1999 00:44:30 +0200 (MDT)
Message-ID: <37CEFF2C.EEC96A9F@hem.passagen.se>
Date: Fri, 03 Sep 1999 00:50:20 +0200
From: rasmus ekman
Organization: .
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: John ffitch , Csound list
Subject: triginstr - new opcode
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
(resend, didn't see this first time - hope it's not cluttering everybody's mailboxes...)
Greetings Csounders,
Here is an opcode which starts new instrument events from orchestra
at k-rate. Events are started every time a triggering signal is non-zero.
Event generation may be limited in two ways: by setting a minimum time
interval between generated events, or by specifying a maximum number
of simultaneous instruments instances. Events may also be deferred.
This opcode may be useful for things like generating strumming gestures,
or for some types of algorithmic composition.
Below are the code changes and two new files (triginstr.h and triginstr.c).
Documentation of the triginstr opcode follows at the end of this post.
Regards,
re
========================
CODE CHANGES
(A bit more to do than for other opcodes: Due to the way Csound handles
instrument event turnoff, this ugen requires some changes to core
stuff like OPARMS, playevents() and kperf() - we have to add a new type
of realtime event.)
In Entry.c, declare in the appropriate places near the top:
------------------------
#include "triginstr.h"
void triginset(TRIGINSTR *p), ktriginstr(TRIGINSTR *p);
------------------------
In Entry.c, anywhere in opcodlst[]:
------------------------
{ "triginstr", S(TRIGINSTR),3, "", "kkkkkz",triginset, ktriginstr, NULL },
========================
In Cs.h, in struct OPARMS, eg line 82 (new line marked >>>):
------------------------
int usingcscore, Linein, Midiin, FMidiin;
>>> int OrcEvts; /* - for triginstr (re Aug 1999) */
int RTevents, ksensing;
========================
Insert.c, among declares, eg line 31:
------------------------
int sensOrcEvent(void); /* For triginstr (re Aug 1999) */
------------------------
Insert.c, function kperf(), on lines 563 - 570:
Change the line marked ">>>", and insert the line marked "++>>":
------------------------
if (O.RTevents) {
if (O.Midiin && (sensType = sensMidi()) /* if MIDI note message */
|| O.FMidiin && kcounter >= FMidiNxtk
&& (sensType = sensFMidi())
>>> || O.Linein && (sensType = sensLine()) /* or Linein event */
++>> || O.OrcEvts && (sensType = sensOrcEvent())) /* or triginstr event (re Aug 1999) */
return(kreq - kcnt); /* do early return */
}
========================
Musmon.c, among header includes, eg line 6,
------------------------
#include "triginstr.h"
------------------------
Musmon.c, function playevents(), at label mtest, line 515:
Replace the lines
mtest:
if (sensType >= 2) { /* Midievent: */
with the following:
------------------------
mtest:
/* Old test: */
/* if (sensType >= 2) { /* Midievent: */
/* New version (re Aug 1999): */
if (sensType == 2 || sensType == 3) { /* Midievent: */
------------------------
NOTE: Somebody may feel queasy about changing the test here.
The present test captures all sensType values above 2. This is unnecessary,
as only 2 and 3 are ever used. This is quite easily verifiable: sensType
is set by calling sensMidi(), sensFMidi(), or sensLine(), as seen in the
code snippet from Insert.c above.
These functions only use direct return values 1 (sensLine), 2 (sensMidi)
or 3 (sensFMidi) - or zero for no event.
The dark horse is MacSensMidi(), which is called from sensMidi()
(#ifdef macintosh), but not provided with the Bath source distribution.
This function is however in the Mills Perf code distribution, and
returns 2 (or zero) as expected.
========================
Musmon.c, function playevents(), around line 470:
At the lines
if (sensType == 1) { /* for Linein, */
e = Linevtblk; /* get its evtblk */
e->p[2] = curp2; /* & insert curp2 */
}
>>> insert new lines here
if (!kdone) /* if null duration, */
goto mtest; /* chk for midi on-off */
Insert the following case (now the old lines are marked with >>>):
------------------------
>>> if (sensType == 1) { /* for Linein, */
>>> e = Linevtblk; /* get its evtblk */
>>> e->p[2] = curp2; /* & insert curp2 */
>>> }
else if(sensType == 4) { /* Realtime orc event (re Aug 1999) */
EVTNODE *evtlist = OrcTrigEvts.nxtevt;
while (evtlist && evtlist->kstart <= kcounter) {
int insno = evtlist->insno;
e = &evtlist->evt;
evtlist = OrcTrigEvts.nxtevt = evtlist->nxtevt;
/* If several events pending we must insert all but one
- code copied from switch(e->opcod) case 'i' below */
if(evtlist && evtlist->kstart <= kcounter) {
if (O.Beatmode && e->p3orig >= 0.)
e->p[3] = e->p3orig * betsiz;
if (n = insert(insno, e)) { /* alloc,init,activate */
printf("\t\t T%7.3f",curp2);
printf("triginstr note deleted. i%d had %d init errors\n",
insno, n);
perferrcnt++;
}
}
}
if(OrcTrigEvts.nxtevt == NULL) O.OrcEvts = 0;
}
>>> if (!kdone) /* if null duration, */
>>> goto mtest; /* chk for midi on-off */
========================
NEW FILES:
triginstr.h:
------------------------
/*****************************************************************/
/* triginstr - Start instrument events at k-rate from orchestra. */
/* August 1999 by rasmus ekman. */
/*****************************************************************/
typedef struct {
OPDS h;
FLOAT *trigger, *mintime, *maxinst;
FLOAT *args[PMAX+1];
FLOAT prvmintim;
long timrem, prvktim, kadjust;
} TRIGINSTR;
typedef struct eventnode {
EVTBLK evt; /* Must be first in struct so it can be typecast & freed */
struct eventnode *nxtevt;
int kstart, insno;
} EVTNODE;
extern EVTNODE OrcTrigEvts;
extern int sensOrcEvent(void);
========================
triginstr.c:
------------------------
/******************************************************************************/
/* triginstr - Ignite instrument events at k-rate from orchestra. */
/* August 1999 by rasmus ekman. */
/* Changes made also to Cs.h, Musmon.c and Insert.c; look for "(re Aug 1999)" */
/******************************************************************************/
#include "cs.h"
#include "triginstr.h"
/* Some global declarations we need */
extern INSTRTXT **instrtxtp; /* List of instrument declarations (orchestra) */
extern INSDS actanchor; /* Chain of active instrument instances */
extern void infoff(FLOAT p1); /* Turn off an indef copy of instr p1 */
extern long kcounter; /* Count of k-periods throughout performance */
extern int sensType; /* 0=score evt, 1=Linein, 2/3=midi, 4=triginstr */
#define FZERO (0.0f) /* (Shouldn't there be global decl's for these?) */
#define FONE (1.0f)
EVTNODE OrcTrigEvts; /* List of started events, used in playevents() (Musmon.c) */
/* Called from kperf() to see if any event to turn on */
int sensOrcEvent(void) {
if(OrcTrigEvts.nxtevt && OrcTrigEvts.nxtevt->kstart <= kcounter)
return(4); /* sensType value (0=score,1=line,2/3=midi) */
else return(0);
}
void ktriginstr(TRIGINSTR *p);
void triginset(TRIGINSTR *p) {
p->prvmintim = *p->mintime;
p->timrem = 0;
/* An instrument is initialised before kcounter is incremented for
this k-cycle, and begins playing after kcounter++.
Therefore, if we should start something at the very first k-cycle of
performance, we must thus do it now, lest it be one k-cycle late.
But in ktriginstr() we'll need to use kcounter-1 to set the start time
of new events. So add a separate variable for the kcounter offset (-1). */
if(kcounter == 0 && *p->trigger > FZERO && *p->args[1] <= FZERO) {
p->kadjust = 0; /* No kcounter offset at this time */
ktriginstr(p);
}
p->kadjust = -1; /* Set kcounter offset for perf-time */
return;
}
void ktriginstr(TRIGINSTR *p) { /* k-rate event generator */
int i, absinsno, argnum;
FLOAT insno, starttime;
EVTNODE *evtlist, *newnode;
EVTBLK *newevt;
if(*p->trigger == FZERO) /* Only do something if triggered */
return;
/* Get absolute instr num */
insno = *p->args[0];
absinsno = abs((int)insno);
/* Check that instrument is defined */
if(absinsno > maxinsno || instrtxtp[absinsno] == NULL) {
printf("triginstr ignored. Instrument %d undefined\n", absinsno);
perferrcnt++;
return;
}
/* On neg instrnum, turn off a held copy.
(Regardless of mintime/maxinst) */
if(insno < FZERO) {
infoff(-insno);
return;
}
/* Check if mintime has changed */
if(p->prvmintim != *p->mintime) {
long timrem = (int)(*p->mintime * ekr + 0.5f);
if(timrem > 0) {
/* Adjust countdown for new mintime */
p->timrem += timrem - p->prvktim;
p->prvktim = timrem;
} else timrem = 0;
p->prvmintim = *p->mintime;
}
/* Check for rate limit on event generation and count down */
if(*p->mintime > FZERO && --p->timrem > 0)
return;
/* See if there are too many instances already */
if(*p->maxinst >= FONE) {
INSDS *ip;
int numinst = 0;
/* Count active instr instances */
ip = &actanchor;
while ((ip = ip->nxtact) != NULL)
if(ip->insno == absinsno) numinst++;
if(numinst >= (int)*p->maxinst)
return;
}
/* Create the new event */
newnode = (EVTNODE *) mmalloc((long)sizeof(EVTNODE));
newevt = &newnode->evt;
newevt->opcod = 'i';
/* Set start time from kwhen */
starttime = *p->args[1];
if(starttime < FZERO) {
starttime = FZERO;
warning("triginstr warning: negative kwhen reset to zero");
}
/* Add current time (see note about kadjust in triginset() above) */
starttime += (FLOAT)(kcounter + p->kadjust) * onedkr;
newnode->kstart = (long)(starttime * ekr + 0.5f);
newevt->p2orig = starttime;
newevt->p3orig = *p->args[2];
/* Copy all arguments to the new event */
newevt->pcnt = argnum = p->INOCOUNT-3;
for(i = 0; i < argnum; i++)
newevt->p[i+1] = *p->args[i];
newevt->p[2] = starttime; /* Set actual start time in p2 */
newnode->insno = absinsno;
/* Set event activation time in k-cycles */
newnode->kstart = (long)(starttime * ekr + 0.5f);
/* Insert eventnode in list of generated events */
evtlist = &OrcTrigEvts;
while (evtlist->nxtevt) {
if(newnode->kstart < evtlist->nxtevt->kstart) break;
evtlist = evtlist->nxtevt;
}
newnode->nxtevt = evtlist->nxtevt;
evtlist->nxtevt = newnode;
O.RTevents = 1; /* Make sure kperf() looks for RT events */
O.ksensing = 1;
O.OrcEvts = 1; /* - of the appropriate type */
/* Reset min pause counter */
if(*p->mintime > FZERO)
p->timrem = (long)(*p->mintime * ekr + 0.5f);
else p->timrem = 0;
return;
}
========================
DOCUMENTATION:
------------------------
Ignite Instrument Events
triginstr ktrigger, kmintime, kmaxinst, kinstr, kwhen, kdur[, kp4, ... kpN]
Generate new instrument events from orchestra.
This opcode may be useful eg for certain kinds of algorithmic composition.
ARGUMENTS
ktrigger - when non-zero, signal that an instrument instance
should be started.
kmintime - controls the minimal time which is to elapse between
generated events, in seconds. If kmintime <= 0, no time limit is
used. If the kinstr instrument number is negative (to turn off
an instrument), this test is bypassed.
kmaxinst - ceiling for the number of simultaneous instances of
instrument kinstr. If number of existant instances of kinstr
is >= kmaxinst, no event is generated. If kmaxinst is <= 0, it is
not used to limit event generation. If the kinstr instrument
number is negative (to turn off an instrument), this test is
bypassed.
kinstr, kwhen, kdur, ... - same arguments as in score i statements.
The kwhen start time (p2) is measured from the time of the triggering
event, and must be a positive value (or zero).
If an event is deferred by a p2 offset value, the instrument will
not be initialized until the actual time when it should start performing.
PERFORMANCE
triginstr adds a new instrument event to the Csound performance
each time the krate value ktrigger is non-zero. Event generation
may be limited by the kmintime and kmaxinst arguments. The instrument
will be initialized at the time when it actually begins playing.
The arguments for the generated instrument event are the same as
in a score i-statement. The kwhen time (p2) is measured from the time
of the triggering event. If kdur (p3) is zero the instrument will
only do an initialization pass without performance. A negative kdur
value will initiate a held note (see also ihold and i-statements).
Note that while delayed events are pending, and no events are
playing, the performance must be kept going, or Csound will quit.
To guarantee continued performance, the f0 statement may be used
in score (same as eg when playing midi files, or padding score
sections with silence).
EXAMPLES
The offset value is useful for triggering multiple instruments
in fixed relations. Here, two alternating metronomes:
instr 5 ; tick-tock, tick-tock
iBPM init p4
; Instr's 6 and 7 could be eg simple sample players
triginstr 1, 60/iBPM, 0, 6, 0, .5
triginstr 1, 60/iBPM, 0, 7, 30/iBPM, .5
endin
;Score
; Generate events at 150 BPM for 10 secs
i1 0 10 150
This example will create a strumming gesture of p5 notes in p6 seconds
instr 10 ; Strummer
; Pass some values to the strummed instr
koct init p4
iamp init 12000
; Init strum delay so p5 events start in (roughly) p6 seconds
iNumEvts init p5
knum init 0
iDelBase init (p6 / sqrt(iNumEvts)) * 1.7
kdel init 0
; Generate p5 events in the first p5 k-cycles
knum = knum + 1
ktrig = (knum <= iNumEvts ? 1 : 0)
; Strum instr 11, passing pitch and "intended pitch" to pluck
; for some spectral variation. (knum is also passed for diagnostics)
triginstr ktrig, 0, 0, 11, kdel, .5, iamp, cpspch(koct), cpspch(koct) * (knum+2), knum
; Increase delay for next events
kdel = kdel + iDelBase / (knum+1)
; and play a chord (just to do something)
koct = koct +.03
; Don't need this instr after the evts generated, so turn off
if knum < iNumEvts kgoto continue
turnoff
continue:
endin
instr 11 ; Strummed instrument
; print p2, pchoct(octcps(p5)), p6, p7
kamp linseg p4, p3-.1, p4, .1, 0
ar pluck kamp, p5, p6, 0, 1
out ar
endin
; Score
i10 0 .1 6.10 6 .6
i10 1.5 .3 7.00 6 .7
i10 3 .3 6.03 11 1.5
f0 5
e
This example uses xyin to provide gestural control of event generation:
; Orchestra
sr = 22050
kr = 882
ksmps = 25
nchnls = 2
instr 9 ; Generate 1 - 50 events per sec (max 20 simultaneous)
kX, kY xyin .03, .02, 1, 0, 3000, 1, 100
triginstr 1, kX/2, 20, 2, 0, .7, kY, kY/(kX*.5)
endin
instr 12
kamp linseg 15000, p3-.05, 15000, .05, 0
kcps line p4, p3, p5
ar pluck kamp, p4, p5, 0, 1 pan
; Random stereo distribution
a1, a2 locsig ar, rnd(360), 1, 0
outs a1, a2
endin
; Score
f1 0 8192 10 1 ; Sine
i9 0 15
e
Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa29331;
3 Sep 99 1:24 BST
Received: from [144.173.6.14] (helo=exeter.ac.uk)
by shaun.maths.bath.ac.uk with esmtp (Exim 2.12 #1)
id 11Mh9H-0004JM-00
for jpff@maths.bath.ac.uk; Fri, 3 Sep 1999 01:24:11 +0100
Received: from noether [144.173.8.10] by hermes via SMTP (BAA14495); Fri, 3 Sep 1999 01:21:50 +0100 (BST)
Received: from exeter.ac.uk by maths.ex.ac.uk; Fri, 3 Sep 1999 01:21:39 +0100
Received: from rothko.bestweb.net [209.94.100.160] by hermes via ESMTP (BAA15702); Fri, 3 Sep 1999 01:21:38 +0100 (BST)
Received: from goodguy ([216.179.14.66])
by rothko.bestweb.net (8.9.1a/8.9.0) with SMTP id UAA14892
for ; Thu, 2 Sep 1999 20:21:36 -0400 (EDT)
Message-ID: <37CF1343.67278A2B@westnet.com>
Date: Fri, 03 Sep 1999 00:16:03 +0000
From: Larry Troxler
X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.36 i586)
MIME-Version: 1.0
To: csound@maths.ex.ac.uk
Subject: wgpluck fixed (sort of) / wgpluck vs. wgpluck2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk
I have wgpluck mostly working (there were several bugs in the
distributed code).
The reason I say "sort of", is because while I fixed the tuning to be
acceptable for most cases, the way I fixed it isn't optimum. Also there
is at least one dangerous design problem in the code same quantity being
calculated in two different modules (not too bad, except in one case it
is being used to determine memory allocation!).
Maybe if I get a chance I'll clean everything up and sumbmit it, but in
the mean time if someone wants to try this opcode, I could individually
send the two source files. Again, it works, it's just not ideal and not
cleaned up.
wgpluck2: This opcode seems to serve the same purpose as wgpluck, but
rather than using an allpass filter to fix up the tuning, uses
oversampling. I would have used this, except that I thought the
performance might not be good enough for realtime on my Pentium 100
machine. It looked like one could easilly be looking at 20 to 40 X
oversampling. Probably very accurate, but not fast.
Larry Troxler
Received: from wallace.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa29820;
3 Sep 99 5:32 BST
Received: from [144.173.6.14] (helo=exeter.ac.uk)
by wallace.maths.bath.ac.uk with esmtp (Exim 2.12 #1)
id 11MjuO-0004mh-00
for jpff@maths.bath.ac.uk; Fri, 3 Sep 1999 04:21:00 +0100
Received: from noether [144.173.8.10] by hermes via SMTP (FAA05806); Fri, 3 Sep 1999 05:30:16 +0100 (BST)
Received: from exeter.ac.uk by maths.ex.ac.uk; Fri, 3 Sep 1999 05:30:02 +0100
Received: from grynet.passagen.se [195.163.107.36] by hermes via ESMTP (FAA06195); Fri, 3 Sep 1999 05:30:01 +0100 (BST)
Received: from hem.passagen.se (z10-78.stockholm.sbbs2.net [212.112.10.78])
by grynet.passagen.se (8.8.6/8.8.6) with ESMTP id GAA04618
for ; Fri, 3 Sep 1999 06:29:57 +0200 (MDT)
Message-ID: <37CF5026.DE1811E@hem.passagen.se>
Date: Fri, 03 Sep 1999 06:35:50 +0200
From: rasmus ekman
Organization: .
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Csound list
Subject: triginstr - new opcode (re-resend)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk
Hi Csounders,
Here is (doc of) an opcode which starts new instrument events from
the orchestra at k-rate. Events are started every time a triggering
signal is non-zero. Event generation may be limited in two ways:
by setting a minimum time interval between generated events, or
by specifying a maximum number of simultaneous instruments instances.
Events may also be deferred.
This opcode may be useful for things like generating strumming gestures,
or for some types of algorithmic composition.
Unable to grasp the concept of "too large, stoopid", I just sent
the docs plus code files to the list server's dev/null twice
(and of course also to John, both times, for which I apologise).
This post therefore only contains the documentation of the opcode.
If somebody cooks his own Csound and wants to try it, you can
(temporarily) get the full post at
http://hem.passagen.se/rasmuse/triginstr.txt
(Note that it requires some changes to central files cs.h, Musmon.c,
and Insert.c - besides including new files and changing Entry.c -
but the instructions will be, I hope, clear enough.)
Regards,
re
========================
triginstr DOCUMENTATION:
------------------------
Ignite Instrument Events
triginstr ktrigger, kmintime, kmaxinst, kinstr, kwhen, kdur[, kp4, ... kpN]
triginstr adds new instrument events to the Csound performance
whenever the krate value ktrigger is non-zero. Event generation
may be limited by the kmintime and kmaxinst arguments.
This opcode may be useful eg for certain kinds of algorithmic composition.
PERFORMANCE
ktrigger - when non-zero, signal that an instrument instance
should be started.
kmintime - controls the minimal time which is to elapse between
generated events, in seconds. If kmintime <= 0, no time limit is
used. If the kinstr instrument number is negative (to turn off
an instrument), this test is bypassed.
kmaxinst - ceiling for the number of simultaneous instances of
instrument kinstr. If number of existant instances of kinstr
is >= kmaxinst, no event is generated. If kmaxinst is <= 0, it is
not used to limit event generation. If the kinstr instrument
number is negative (to turn off an instrument), this test is
bypassed.
kinstr, kwhen, kdur, ... - same arguments as in score i-statements.
The kwhen start time (p2) is measured from the time of the triggering
event, and must be a positive value (or zero).
If an event is deferred by a p2 offset value, the instrument will
not be initialized until the actual time when it should start performing.
If kdur (p3) is zero the instrument will only do an initialization
pass without performance. A negative kdur value will initiate a held note
(see also ihold and i-statements).
Note that while waiting for delayed events, the performance must
be kept going, or Csound may quit if no score events are expected.
To guarantee continued performance, the f0 statement may be used
in score (same as eg when playing midi files, or to pad score sections
with silence).
EXAMPLES
The offset value is useful for triggering multiple instruments
in fixed relations. Here, two alternating metronomes:
instr 5 ; tick-tock, tick-tock
iBPM init p4
; Instr's 6 and 7 could be eg simple sample players
triginstr 1, 60/iBPM, 0, 6, 0, .5
triginstr 1, 60/iBPM, 0, 7, 30/iBPM, .5
endin
;Score
; Generate events at 150 BPM for 10 secs
i1 0 10 150
e
This example will create a strumming gesture of p5 notes in p6 seconds
instr 10 ; Strummer
; Pass some values to the strummed instr
koct init p4
iamp init 12000
; Init strum delay so p5 events start in (roughly) p6 seconds
iNumEvts init p5
knum init 0
iDelBase init (p6 / sqrt(iNumEvts)) * 1.7
kdel init 0
; Generate p5 events in the first p5 k-cycles
knum = knum + 1
ktrig = (knum <= iNumEvts ? 1 : 0)
; Strum instr 11, passing pitch and "intended pitch" to pluck
; for some spectral variation. (knum is also passed for diagnostics)
triginstr ktrig, 0, 0, 11, kdel, .5, iamp, cpspch(koct), cpspch(koct) * (knum+2), knum
; Increase delay for next events
kdel = kdel + iDelBase / (knum+1)
; and play a chord (just to do something)
koct = koct +.03
; Don't need this instr after the evts generated, so turn off
if knum < iNumEvts kgoto continue
turnoff
continue:
endin
instr 11 ; Strummed instrument
; print p2, pchoct(octcps(p5)), p6, p7
kamp linseg p4, p3-.1, p4, .1, 0
ar pluck kamp, p5, p6, 0, 1
out ar
endin
; Score
i10 0 .1 6.10 6 .6
i10 1.5 .3 7.00 6 .7
i10 3 .3 6.03 11 1.5
f0 5
e
This example uses xyin to provide gestural control of event generation:
; Orchestra
sr = 22050
kr = 882
ksmps = 25
nchnls = 2
instr 9 ; Generate 1-50 events per sec (max 20 simultaneous)
kX, kY xyin .03, .02, 1, 0, 3000, 1, 100
triginstr 1, kX/2, 20, 2, 0, .7, kY, kY/(kX*.5)
endin
instr 12
kamp linseg 15000, p3-.05, 15000, .05, 0
kcps line p4, p3, p5
ar pluck kamp, p4, p5, 0, 1 pan
; Random stereo distribution
a1, a2 locsig ar, rnd(360), 1, 0
outs a1, a2
endin
; Score
f1 0 8192 10 1 ; Sine
i9 0 15
e
Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa29922;
3 Sep 99 7:05 BST
Received: from [144.173.6.14] (helo=exeter.ac.uk)
by shaun.maths.bath.ac.uk with esmtp (Exim 2.12 #1)
id 11MmTZ-0004Tl-00
for jpff@maths.bath.ac.uk; Fri, 3 Sep 1999 07:05:29 +0100
Received: from noether [144.173.8.10] by hermes via SMTP (HAA03203); Fri, 3 Sep 1999 07:03:15 +0100 (BST)
Received: from exeter.ac.uk by maths.ex.ac.uk; Fri, 3 Sep 1999 07:03:08 +0100
Received: from root@news.cube.net [194.97.64.2] by hermes via SMTP (HAA08503); Fri, 3 Sep 1999 07:03:07 +0100 (BST)
Received: from orpheus.selene.cube.net([193.149.39.225]) (1879 bytes) by salyko.cube.net
via smtpd with P:smtp/R:bind_hosts/T:inet_zone_bind_smtp
(sender: )
id
for ; Fri, 3 Sep 1999 08:03:06 +0200 (MEST)
(Smail-3.2.0.106 1999-Mar-31 #1 built 1999-Sep-2)
Received: from hermes by orpheus.selene.cube.net (NX5.67f2/NX3.0M)
id AA28775; Fri, 3 Sep 99 08:02:34 +0200
Message-Id: <9909030602.AA28775@orpheus.selene.cube.net>
Received: by hermes.selene.cube.net (NX5.67g/NX3.0X)
id AA01051; Fri, 3 Sep 99 08:02:36 +0200
Mime-Version: 1.0 (NeXT Mail 4.2mach v148)
Content-Type: multipart/alternative; boundary=NeXT-Mail-1222875118-1
Content-Transfer-Encoding: 7bit
Received: by NeXT.Mailer (1.148)
From: Peter =?iso-8859-1?Q?Neub=E4cker?=
Date: Fri, 3 Sep 99 08:02:35 +0200
To: csound@maths.ex.ac.uk
Subject: triginstr - new opcode (re-resend)
Reply-To: peter@orpheus.selene.cube.net
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk
--NeXT-Mail-1222875118-1
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
> triginstr
Great - I am looking forward to it!
Looking over general csound-sourcecode, I had the
impression that csound doesn`t provide the possibility
to take an arbitrary number of optional k-parameters
for an opcode, only i-parameters. For example, in
schedule you always have to reinit the opcode to
take current k-values.
Did you change that for triginstr?
Peter
--NeXT-Mail-1222875118-1
Content-Type: text/enriched; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
> triginstr
Great - I am looking forward to it!
Looking over general csound-sourcecode, I had the
impression that csound doesn`t provide the possibility
to take an arbitrary number of optional k-parameters
for an opcode, only i-parameters. For example, in
schedule you always have to reinit the opcode to
take current k-values.
Did you change that for triginstr?
Peter
--NeXT-Mail-1222875118-1--
Received: from wallace.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa29967;
3 Sep 99 7:40 BST
Received: from [144.173.6.14] (helo=exeter.ac.uk)
by wallace.maths.bath.ac.uk with esmtp (Exim 2.12 #1)
id 11MluB-0004tL-00
for jpff@maths.bath.ac.uk; Fri, 3 Sep 1999 06:28:55 +0100
Received: from noether [144.173.8.10] by hermes via SMTP (HAA10055); Fri, 3 Sep 1999 07:38:04 +0100 (BST)
Received: from exeter.ac.uk by maths.ex.ac.uk; Fri, 3 Sep 1999 07:37:57 +0100
Received: from root@news.cube.net [194.97.64.2] by hermes via SMTP (HAA09411); Fri, 3 Sep 1999 07:37:57 +0100 (BST)
Received: from orpheus.selene.cube.net([193.149.39.225]) (1428 bytes) by salyko.cube.net
via smtpd with P:smtp/R:bind_hosts/T:inet_zone_bind_smtp
(sender: )
id
for ; Fri, 3 Sep 1999 08:37:51 +0200 (MEST)
(Smail-3.2.0.106 1999-Mar-31 #1 built 1999-Sep-2)
Received: from hermes by orpheus.selene.cube.net (NX5.67f2/NX3.0M)
id AA28804; Fri, 3 Sep 99 08:37:19 +0200
Message-Id: <9909030637.AA28804@orpheus.selene.cube.net>
Received: by hermes.selene.cube.net (NX5.67g/NX3.0X)
id AA01061; Fri, 3 Sep 99 08:37:22 +0200
Content-Type: text/plain
Mime-Version: 1.0 (NeXT Mail 4.2mach v148)
Received: by NeXT.Mailer (1.148)
From: Peter Neubacker
Date: Fri, 3 Sep 99 08:37:21 +0200
To: csound@maths.ex.ac.uk
Subject: Re: triginstr - new opcode (re-resend)
Reply-To: peter@orpheus.selene.cube.net
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk
With triginstr, does the mechanism of fractional
instrument number work for accessing defined
instances of that instrument?
I am thinking of updating parameters for instrument
instances by sending held notes something like
kinstance init 0
kinstance = (kinstance < instcount ? kinstance+1 : 1)
kinstrnum = 2 + kinstance/100
triginstr ktrig, 0, 0, kinstrnum, 0, -1, kparam1, ....
In a score, you would write explicitly
i 2.01 ......
i 2.02 ......
but when instance numbers are calculated at runtime,
there might be someting like
i 2.0199999999 instead of i 2.02 ....
That may be a different instance -
how would that be handled internally?...
Peter
Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa00251;
3 Sep 99 9:47 BST
Received: from [144.173.6.14] (helo=exeter.ac.uk)
by shaun.maths.bath.ac.uk with esmtp (Exim 2.12 #1)
id 11Mp0p-0004W4-00
for jpff@maths.bath.ac.uk; Fri, 3 Sep 1999 09:47:59 +0100
Received: from noether [144.173.8.10] by hermes via SMTP (JAA01586); Fri, 3 Sep 1999 09:44:09 +0100 (BST)
Received: from exeter.ac.uk by maths.ex.ac.uk; Fri, 3 Sep 1999 09:43:55 +0100
Received: from tigger.scc.uni-weimar.de [141.54.1.3] by hermes via ESMTP (JAA01985); Fri, 3 Sep 1999 09:43:50 +0100 (BST)
Received: from chewa (pmclient49.scc.uni-weimar.de [141.54.7.58])
by tigger.scc.uni-weimar.de (8.9.2/8.9.2) with SMTP id KAA10841;
Fri, 3 Sep 1999 10:43:36 +0200 (MET DST)
From: Torsten Anders
To: Larry Troxler , csound@maths.ex.ac.uk
Subject: Re: ugen test-level status in doc?
Date: Fri, 3 Sep 1999 11:32:12 +0200
X-Mailer: KMail [version 1.0.17]
Content-Type: text/plain
References: <37CC835E.59DB4482@westnet.com>
MIME-Version: 1.0
Message-Id: <99090311465602.00232@chewa>
Content-Transfer-Encoding: quoted-printable
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk
seems no one had answered on that so I dare to:
I think such a database could really improve the usabily of csound (at le=
ast
for me...). And I am willing to collect infos.
But I think: if it is used as a collection of know problems, the really q=
uestion
is: how keep such a db up to date?
Torsten Anders
On Wed, 01 Sep 1999 you wrote:
>Hi, I wonder if anyone else thinks that it would be very usefull if
>there were some easy way to compile some sort of database of the
>"correctness" of the various csound orc ugens and function generators.
>In other words, is there a workable way to provide some sort of
>information as to what ugens are generally known to work, and which ones
>are either untested or known to be broken?=20
>
>I'm thinking both of the person who is casually trying out csound for
>the first time, and most likely does not want to immediately venture
>into source-level debugging, and also of people like me, whose time is
>limited, and hence might in some circumstances want to avoid using
>opcodes that have not been verified to work as advertised.
>
>I suspect that at any given point in time, probably somewhere between 10
>and 50 percent of the included opcodes don't work correctly in many
>common circumstances. This is just a wild guess based on my own
>experience, and from my reading of this mailing list.=20
>
>So, it would be helpfull to know which of these ugens are heavilly used
>and generally assumed to work, and which are the ones that haven't been
>really exercised by anyone who knows enough to tell that they don't work
>right.
>
>Of course, the problem here is how to compile this sort of information.
>I don't have an answer for this. Maybe for starters, if people would
>post to the list when they have used a certain ugen and found no
>problems? Of course, this would add a lot of traffic to this list, but
>maybe it would be worth it.=20
>
>Larry Troxler
Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa00387;
3 Sep 99 10:31 BST
Received: from [144.173.6.14] (helo=exeter.ac.uk)
by shaun.maths.bath.ac.uk with esmtp (Exim 2.12 #1)
id 11Mpgl-0004XS-00
for jpff@maths.bath.ac.uk; Fri, 3 Sep 1999 10:31:19 +0100
Received: from noether [144.173.8.10] by hermes via SMTP (KAA08628); Fri, 3 Sep 1999 10:27:32 +0100 (BST)
Received: from exeter.ac.uk by maths.ex.ac.uk; Fri, 3 Sep 1999 10:27:19 +0100
Received: from hawk.glasnet.ru [193.124.5.50] by hermes via ESMTP (KAA01327); Fri, 3 Sep 1999 10:27:18 +0100 (BST)
Received: from mustang.glasnet.ru([193.124.5.62]) (1039 bytes) by hawk.glasnet.ru
via sendmail with P:esmtp/R:inet_hosts/T:inet_zone_smtp
(sender: )
id
for ; Fri, 3 Sep 1999 13:27:17 +0400 (MSD)
(Smail-3.2.0.106 1999-Mar-31 #3 built DST-Apr-19)
Received: from default([195.218.251.120]) (657 bytes) by mustang.glasnet.ru
via sendmail with P:esmtp/R:smart_host/T:smtp
(sender: )
id
for ; Fri, 3 Sep 1999 13:24:31 +0400 (MSD)
(Smail-3.2.0.106 1999-Mar-31 #3 built 1999-Jun-9)
Message-Id:
From: Sergey Batov
To: Csound Mail-list
Subject: formats of sound files
Date: Fri, 3 Sep 1999 11:16:30 +0400
X-MSMail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1155
MIME-Version: 1.0
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: 7bit
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk
Dear Csounders!
Where in Internet is it possible to find the most complete and
detailed description of the sound files formats?
Thanks in advance.
Regards,
Sergey Batov batov@glasnet.ru
Received: from wallace.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa00432;
3 Sep 99 10:43 BST
Received: from [144.173.6.14] (helo=exeter.ac.uk)
by wallace.maths.bath.ac.uk with esmtp (Exim 2.12 #1)
id 11Mokt-00051Q-00
for jpff@maths.bath.ac.uk; Fri, 3 Sep 1999 09:31:31 +0100
Received: from noether [144.173.8.10] by hermes via SMTP (KAA06857); Fri, 3 Sep 1999 10:39:46 +0100 (BST)
From: Dspondike@aol.com
Received: from exeter.ac.uk by maths.ex.ac.uk; Fri, 3 Sep 1999 10:39:34 +0100
Received: from imo28.mx.aol.com [198.81.17.72] by hermes via ESMTP (KAA04762); Fri, 3 Sep 1999 10:39:33 +0100 (BST)
Received: from Dspondike@aol.com
by imo28.mx.aol.com (mail_out_v22.4.) id 2FPOa22755 (4575);
Fri, 3 Sep 1999 05:38:55 -0400 (EDT)
Message-ID: <6330bfd5.2500f12f@aol.com>
Date: Fri, 3 Sep 1999 05:38:55 EDT
Subject: Re: formats of sound files
To: batov@glasnet.ru, csound@maths.ex.ac.uk
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: AOL for Macintosh sub 54
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk
In a message dated 9/3/99 9:28:14 AM, batov@glasnet.ru writes:
>Where in Internet is it possible to find the most complete and
>detailed description of the sound files formats?
>
I don't know if they are the most complete, but I have a couple of links to
audio file format webpages at
http://members.aol.com/dspondike/mnr/mnrcompmus.html#webgm
David Spondike
Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa00596;
3 Sep 99 12:21 BST
Received: from [144.173.6.14] (helo=exeter.ac.uk)
by shaun.maths.bath.ac.uk with esmtp (Exim 2.12 #1)
id 11MrPO-0004aN-00
for jpff@maths.bath.ac.uk; Fri, 3 Sep 1999 12:21:30 +0100
Received: from noether [144.173.8.10] by hermes via SMTP (MAA03658); Fri, 3 Sep 1999 12:19:12 +0100 (BST)
Received: from exeter.ac.uk by maths.ex.ac.uk; Fri, 3 Sep 1999 12:18:59 +0100
Received: from grynet.passagen.se [195.163.107.36] by hermes via ESMTP (MAA07877); Fri, 3 Sep 1999 12:18:58 +0100 (BST)
Received: from hem.passagen.se (z17-5-27.sbbs2.net [212.112.5.27])
by grynet.passagen.se (8.8.6/8.8.6) with ESMTP id NAA21176
for ; Fri, 3 Sep 1999 13:18:56 +0200 (MDT)
Message-ID: <37CFAFFB.A3F3C012@hem.passagen.se>
Date: Fri, 03 Sep 1999 13:24:43 +0200
From: rasmus ekman
Organization: .
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Csound list
Subject: Re: formats of sound files
References:
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk
Sergey Batov wrote:
>
>
> Where in Internet is it possible to find the most complete and
> detailed description of the sound files formats?
www.wotsit.org has almost all file formats of every kind.
Highly recommended.
re
Received: from wallace.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa00603;
3 Sep 99 12:23 BST
Received: from [144.173.6.14] (helo=exeter.ac.uk)
by wallace.maths.bath.ac.uk with esmtp (Exim 2.12 #1)
id 11MqJs-000570-00
for jpff@maths.bath.ac.uk; Fri, 3 Sep 1999 11:11:44 +0100
Received: from noether [144.173.8.10] by hermes via SMTP (MAA03688); Fri, 3 Sep 1999 12:21:17 +0100 (BST)
Received: from exeter.ac.uk by maths.ex.ac.uk; Fri, 3 Sep 1999 12:21:06 +0100
Received: from grynet.passagen.se [195.163.107.36] by hermes via ESMTP (MAA04751); Fri, 3 Sep 1999 12:21:05 +0100 (BST)
Received: from hem.passagen.se (z17-5-27.sbbs2.net [212.112.5.27])
by grynet.passagen.se (8.8.6/8.8.6) with ESMTP id NAA21278
for ; Fri, 3 Sep 1999 13:21:03 +0200 (MDT)
Message-ID: <37CFB07E.740748BE@hem.passagen.se>
Date: Fri, 03 Sep 1999 13:26:54 +0200
From: rasmus ekman
Organization: .
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
CC: csound@maths.ex.ac.uk
Subject: Re: triginstr - new opcode (re-resend)
References: <9909030602.AA28775@orpheus.selene.cube.net>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by exeter.ac.uk id MAA04751
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk
Peter Neub=E4cker wrote:
>=20
> > triginstr
> Looking over general csound-sourcecode, I had the impression=20
> that csound doesn't provide the possibility to take an arbitrary=20
> number of optional k-parameters for an opcode, only i-parameters.=20
Nonono! I'm not sure if the parser actually choked on it earlier,
but it was possible to get around several years ago. The 'm' input
argument code in Entry.c just tells the parser to skip checks and=20
pass along the rest of the arguments, then the opcode will handle=20
them internally.
(I use the 'z' code, which was added in 3.57 or so, but that's just
a notational clarification, it could as well use "km" instead.
See comments in Entry.c after declarations, before opcodlst)
> For example, in schedule you always have to reinit the opcode to=20
> take current k-values. Did you change that for triginstr?
Schedule is defined to work at i-time, with i-time arguments, so
the trick of reiniting to use it at k-rate is a hack.=20
> With triginstr, does the mechanism of fractional instrument number=20
> work for accessing defined instances of that instrument?
Yes, it should - I've done nothing to stop that. The events
are just sent to Csound's standard insertion routine. (gotta
test this now.)
> but when instance numbers are calculated at runtime, there might be=20
> someting like i 2.0199999999 instead of i 2.02 ....
Yes. So you'd have to be somewhat careful how the numbers are defined.
Eg set the number by adding a fraction to the instr number rather than=20
as the result of a division.
Cheers,
re
Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa00672;
3 Sep 99 13:01 BST
Received: from [144.173.6.14] (helo=exeter.ac.uk)
by shaun.maths.bath.ac.uk with esmtp (Exim 2.12 #1)
id 11Ms2S-0004bM-00
for jpff@maths.bath.ac.uk; Fri, 3 Sep 1999 13:01:52 +0100
Received: from noether [144.173.8.10] by hermes via SMTP (MAA06066); Fri, 3 Sep 1999 12:58:55 +0100 (BST)
Received: from exeter.ac.uk by maths.ex.ac.uk; Fri, 3 Sep 1999 12:58:43 +0100
Received: from mail.infohouse.com [204.143.176.4] by hermes via ESMTP (MAA03714); Fri, 3 Sep 1999 12:58:42 +0100 (BST)
Received: from [204.143.224.91] (dial-up091.infohouse.com)
by mail.infohouse.com (Post.Office MTA v3.5.3 release 223
ID# 141-59479U3500L350S0V35) with ESMTP id com;
Fri, 3 Sep 1999 07:51:29 -0400
X-Sender: ic11748@mail.infohouse.com
Message-Id:
In-Reply-To: <99090311465602.00232@chewa>
References: <37CC835E.59DB4482@westnet.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 3 Sep 1999 08:00:09 +0100
To: Torsten Anders , csound@maths.ex.ac.uk
MMDF-Warning: Parse error in original version of preceding line at UK.AC.Bath.maths.omphalos
From: tolve
Subject: Re: ugen test-level status in doc?
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk
i have been doing quite a bit of database development lately in filemaker
pro which runs cross platform on mac, windows, and can work off the web as
well. would be willing to create structure to deal with the information on
opcode status in filemaker that could be easily updated by any number of
people given access to it on web and willing to do the *hard* work of
compiling and entering the "easy to update" information.
disclaimer: i work on mac and have not ever tested on windows though many
people do run filemaker on both (allegedly fast becoming the best selling
database). and have never posted any of my databases on the web. filemaker
list postings indicate that there shouldn't be too many wrinkles.
tolve
>seems no one had answered on that so I dare to:
>
>I think such a database could really improve the usabily of csound (at least
>for me...). And I am willing to collect infos.
>But I think: if it is used as a collection of know problems, the really
>question
>is: how keep such a db up to date?
>
>Torsten Anders
>
>
>On Wed, 01 Sep 1999 you wrote:
>>Hi, I wonder if anyone else thinks that it would be very usefull if
>>there were some easy way to compile some sort of database of the
>>"correctness" of the various csound orc ugens and function generators.
>>In other words, is there a workable way to provide some sort of
>>information as to what ugens are generally known to work, and which ones
>>are either untested or known to be broken?
>>
>>I'm thinking both of the person who is casually trying out csound for
>>the first time, and most likely does not want to immediately venture
>>into source-level debugging, and also of people like me, whose time is
>>limited, and hence might in some circumstances want to avoid using
>>opcodes that have not been verified to work as advertised.
>>
>>I suspect that at any given point in time, probably somewhere between 10
>>and 50 percent of the included opcodes don't work correctly in many
>>common circumstances. This is just a wild guess based on my own
>>experience, and from my reading of this mailing list.
>>
>>So, it would be helpfull to know which of these ugens are heavilly used
>>and generally assumed to work, and which are the ones that haven't been
>>really exercised by anyone who knows enough to tell that they don't work
>>right.
>>
>>Of course, the problem here is how to compile this sort of information.
>>I don't have an answer for this. Maybe for starters, if people would
>>post to the list when they have used a certain ugen and found no
>>problems? Of course, this would add a lot of traffic to this list, but
>>maybe it would be worth it.
>>
>>Larry Troxler
Received: from wallace.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa00694;
3 Sep 99 13:09 BST
Received: from [144.173.6.14] (helo=exeter.ac.uk)
by wallace.maths.bath.ac.uk with esmtp (Exim 2.12 #1)
id 11Mr2W-00059J-00
for jpff@maths.bath.ac.uk; Fri, 3 Sep 1999 11:57:52 +0100
Received: from noether [144.173.8.10] by hermes via SMTP (NAA08016); Fri, 3 Sep 1999 13:06:48 +0100 (BST)
Received: from exeter.ac.uk by maths.ex.ac.uk; Fri, 3 Sep 1999 13:06:31 +0100
Received: from mail.infohouse.com [204.143.176.4] by hermes via ESMTP (NAA08562); Fri, 3 Sep 1999 13:06:30 +0100 (BST)
Received: from [204.143.224.91] (dial-up091.infohouse.com)
by mail.infohouse.com (Post.Office MTA v3.5.3 release 223
ID# 141-59479U3500L350S0V35) with ESMTP id com;
Fri, 3 Sep 1999 07:59:17 -0400
X-Sender: ic11748@mail.infohouse.com
Message-Id:
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 3 Sep 1999 08:07:57 +0100
To: csound@maths.ex.ac.uk, Torsten Anders ,
Larry Troxler , csound@maths.ex.ac.uk
MMDF-Warning: Parse error in original version of preceding line at UK.AC.Bath.maths.omphalos
From: tolve
Subject: Re: ugen test-level status in doc?
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk
let me add: of course any platform should be able to view on web.
tolve
>Date: Fri, 3 Sep 1999 08:00:09 +0100
>To: Torsten Anders ,
>
>From: tolve
>Subject: Re: ugen test-level status in doc?
>Cc:
>Bcc:
>X-Attachments:
>
>i have been doing quite a bit of database development lately in filemaker
>pro which runs cross platform on mac, windows, and can work off the web as
>well. would be willing to create structure to deal with the information on
>opcode status in filemaker that could be easily updated by any number of
>people given access to it on web and willing to do the *hard* work of
>compiling and entering the "easy to update" information.
>
>disclaimer: i work on mac and have not ever tested on windows though many
>people do run filemaker on both (allegedly fast becoming the best selling
>database). and have never posted any of my databases on the web. filemaker
>list postings indicate that there shouldn't be too many wrinkles.
>
>tolve
>
>>seems no one had answered on that so I dare to:
>>
>>I think such a database could really improve the usabily of csound (at least
>>for me...). And I am willing to collect infos.
>>But I think: if it is used as a collection of know problems, the really
>>question
>>is: how keep such a db up to date?
>>
>>Torsten Anders
>>
>>
>>On Wed, 01 Sep 1999 you wrote:
>>>Hi, I wonder if anyone else thinks that it would be very usefull if
>>>there were some easy way to compile some sort of database of the
>>>"correctness" of the various csound orc ugens and function generators.
>>>In other words, is there a workable way to provide some sort of
>>>information as to what ugens are generally known to work, and which ones
>>>are either untested or known to be broken?
>>>
>>>I'm thinking both of the person who is casually trying out csound for
>>>the first time, and most likely does not want to immediately venture
>>>into source-level debugging, and also of people like me, whose time is
>>>limited, and hence might in some circumstances want to avoid using
>>>opcodes that have not been verified to work as advertised.
>>>
>>>I suspect that at any given point in time, probably somewhere between 10
>>>and 50 percent of the included opcodes don't work correctly in many
>>>common circumstances. This is just a wild guess based on my own
>>>experience, and from my reading of this mailing list.
>>>
>>>So, it would be helpfull to know which of these ugens are heavilly used
>>>and generally assumed to work, and which are the ones that haven't been
>>>really exercised by anyone who knows enough to tell that they don't work
>>>right.
>>>
>>>Of course, the problem here is how to compile this sort of information.
>>>I don't have an answer for this. Maybe for starters, if people would
>>>post to the list when they have used a certain ugen and found no
>>>problems? Of course, this would add a lot of traffic to this list, but
>>>maybe it would be worth it.
>>>
>>>Larry Troxler
>
>
>
Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa00700;
3 Sep 99 13:09 BST
Received: from [144.173.6.14] (helo=exeter.ac.uk)
by shaun.maths.bath.ac.uk with esmtp (Exim 2.12 #1)
id 11MsA9-0004bs-00
for jpff@maths.bath.ac.uk; Fri, 3 Sep 1999 13:09:49 +0100
Received: from noether [144.173.8.10] by hermes via SMTP (NAA18083); Fri, 3 Sep 1999 13:06:52 +0100 (BST)
Received: from exeter.ac.uk by maths.ex.ac.uk; Fri, 3 Sep 1999 13:06:36 +0100
Received: from mail.infohouse.com [204.143.176.4] by hermes via ESMTP (NAA08114); Fri, 3 Sep 1999 13:06:30 +0100 (BST)
Received: from [204.143.224.91] (dial-up091.infohouse.com)
by mail.infohouse.com (Post.Office MTA v3.5.3 release 223
ID# 141-59479U3500L350S0V35) with ESMTP id com;
Fri, 3 Sep 1999 07:59:17 -0400
X-Sender: ic11748@mail.infohouse.com
Message-Id:
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 3 Sep 1999 08:07:57 +0100
To: csound@maths.ex.ac.uk, Torsten Anders ,
Larry Troxler , csound@maths.ex.ac.uk
MMDF-Warning: Parse error in original version of preceding line at UK.AC.Bath.maths.omphalos
From: tolve
Subject: Re: ugen test-level status in doc?
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk
let me add: of course any platform should be able to view on web.
tolve
>Date: Fri, 3 Sep 1999 08:00:09 +0100
>To: Torsten Anders ,
>
>From: tolve
>Subject: Re: ugen test-level status in doc?
>Cc:
>Bcc:
>X-Attachments:
>
>i have been doing quite a bit of database development lately in filemaker
>pro which runs cross platform on mac, windows, and can work off the web as
>well. would be willing to create structure to deal with the information on
>opcode status in filemaker that could be easily updated by any number of
>people given access to it on web and willing to do the *hard* work of
>compiling and entering the "easy to update" information.
>
>disclaimer: i work on mac and have not ever tested on windows though many
>people do run filemaker on both (allegedly fast becoming the best selling
>database). and have never posted any of my databases on the web. filemaker
>list postings indicate that there shouldn't be too many wrinkles.
>
>tolve
>
>>seems no one had answered on that so I dare to:
>>
>>I think such a database could really improve the usabily of csound (at least
>>for me...). And I am willing to collect infos.
>>But I think: if it is used as a collection of know problems, the really
>>question
>>is: how keep such a db up to date?
>>
>>Torsten Anders
>>
>>
>>On Wed, 01 Sep 1999 you wrote:
>>>Hi, I wonder if anyone else thinks that it would be very usefull if
>>>there were some easy way to compile some sort of database of the
>>>"correctness" of the various csound orc ugens and function generators.
>>>In other words, is there a workable way to provide some sort of
>>>information as to what ugens are generally known to work, and which ones
>>>are either untested or known to be broken?
>>>
>>>I'm thinking both of the person who is casually trying out csound for
>>>the first time, and most likely does not want to immediately venture
>>>into source-level debugging, and also of people like me, whose time is
>>>limited, and hence might in some circumstances want to avoid using
>>>opcodes that have not been verified to work as advertised.
>>>
>>>I suspect that at any given point in time, probably somewhere between 10
>>>and 50 percent of the included opcodes don't work correctly in many
>>>common circumstances. This is just a wild guess based on my own
>>>experience, and from my reading of this mailing list.
>>>
>>>So, it would be helpfull to know which of these ugens are heavilly used
>>>and generally assumed to work, and which are the ones that haven't been
>>>really exercised by anyone who knows enough to tell that they don't work
>>>right.
>>>
>>>Of course, the problem here is how to compile this sort of information.
>>>I don't have an answer for this. Maybe for starters, if people would
>>>post to the list when they have used a certain ugen and found no
>>>problems? Of course, this would add a lot of traffic to this list, but
>>>maybe it would be worth it.
>>>
>>>Larry Troxler
>
>
>
|