> Many thanks, Rasmus.
>
> I'd been trying things out before I received your reply and some of what
you
> say has been experienced by me.
>
> One fudge, which seemed to work, for the problem of schedwhen switching
off
> the scheduled instrument when its own instrument ends is to trigger an
> intermediary instrument which contains schedule. I don't have the orch
with
> me but here is a description.
>
> ie.
> instr    1
> schedwhen "intrs 2 when something happens"
> endin
>
> instr    2
> schedule "instr 3"
> endin
>
> instr    3
> "carry out the scheduled event"
> endin
>
> I've used this in realtime to trigger an event when a signal crosses a
> threshold. It seems to work, but I'm not sure about what is going on
> internally, so to speak.
>
> Thanks for your advice. I do hope that the problems can be overcome and
the
> functionality extended to enable multiple triggering of schedwhen.
>
> Cheers,
> Richard Bowers.
>
> > richard bowers wrote:
> > >
> > > I understand that the opcodes schedule and schedwhen will only operate
> once
> > > in a single call to the instrument containing them. Is that correct?
> >
> > Yes. schedule only works at i-time and schedwhen has an internal
> > switch that is set to "off" after generating the event.
> >
> > Note that these opcodes are rather buggy:
> > First, they can not create deferred events (by setting i/kwhen > 0),
> > so the events are always started immediately. Any attempt to defer
> > events will give them wrong ringtime, namely i/kwhen + i/kdur, while
> > the turnoff time will be correctly set to start time+dur, which means
> > the instr will be around (at least) from generation time through to
> > deferred time + dur (ie def.time + p3).
> >
> > (Programmers note: As far as I can determine, there is no simple way
> > of creating deferred events from an opcode context in Csound, so I
> > wouldn't care to try to fix this feature, rather disallow it until
> > the rest is working.)
> >
> > Secondly, the generated events will not be turned off correctly,
> > but be left hanging, unless there has been some "real" score
> > (or midi or line input) event in the meantime.
> >
> > Prognotes: This is a complication in any Csound event generation from
> > an opcode.  Event turnoff is not handled by kperf() (k-rate
performance),
> > but by playevents() (the score event scheduler, which calls kperf()
> > to run until next score event). kperf() returns only for new events
> > or for event turnoff occasions, but may be expired early by "realtime"
> > (midi, midi file or line input) events. Search for the variable
> > "sensType" in sources if you want to see how this works.
> >
> > Both sched* ugens call schedofftim() to set the turnoff time for
> > the generated event. The time is indeed set, but this is no help since
> > kperf() as noted doesn't check for turnoff. It does happen to work
> > for schedule since this opcode generates events at i-time, and so
> > will have the turnoff logged in playevents() for free before the first
> > k-cycle of the calling instr.
> >
> > My solution to this problem (yes, I've been working on and off for the
> > last few weeks to create an opcode to generate events at k-rate)
> > is to define a new "realtime" event, and do some changes to playevents()
> > and kperf() to have it handled. Not tested enough for publishing yet,
> > as I for one don't think that the compiler does all necessary QA...
> >
> > Thirdly, since they were created by copying a fair chunk of Csound core
> > code (the insert() func.) and doing some changes to that (rather than
> > setting up some scheme which involves calling this function), they are
> > (and will keep getting) out of synch with changes in that code,
> specifically,
> > I believe recent stuff like cpuprc and maxalloc will not work correctly
> > for instr's that have had events generated by sched* ugens.
> >
> > Finally, schedwhen shifts the arguments so that p4= p3, p5= intended p4
> etc
> > in the generated instrument. This one is trivial to fix (it has already
> > been done for schedule at one time).
> >
> >
> > In conclusion, besides wondering what the point of these opcodes is,
> > I'm curious as to whether they were tested _at_all_ before publishing?
> > (Usually I don't complain about stuff without trying to fix it,
> > but after looking at them I simply don't like them, and think they
> > should be taken out and sh (*ahem* deprecated and deleted)).
> >
> > Demonstration: The below csd file should generate one 2.33 second beep
> > after 0.5 seconds, and one after 5 seconds (modulus k-precision).
> > Just see what you get...
> >
> > Regards,
> >
> > re
> >
> >
> > ----------------------
> > schedbug.csd - demo some bugs in sched* opcodes
> > ----------------------
> >
> > 
> > ;
> >
> > ;
> > 
> > sr = 22050
> > kr = 441
> > ksmps = 50
> > nchnls = 1
> >
> > instr 1
> > ; Start i13 after .5 sec (not)
> > schedule 13, .5, 2.33, 550, 0
> > endin
> >
> > instr 2
> > ; Start i3 after 1 sec
> > ;   Since this doesn't work, it starts after 4.0 instead of 5.0 secs
> > ; It should be turned off after 2.33 secs, but hangs until next score
> event
> > schedwhen 1, 13, 1, 2.33, 440
> > endin
> >
> > instr 13
> > ; itime is actual start time, p2 is the intended,
> > ; and p4=p3, p5=p4 if started by schedwhen
> > itime times
> > print itime, p2, p3, p4, p5
> >
> > ; Since p4 won't always be correct, we set a start pitch here
> > kpitch line 440, p3, p4
> > ; Now we're naughty to rub in the point: this linseg continues beyond p3
> > ; - but the error shows even if you remove the last ", .5, 20000" args
> > kamp linseg 25000, p3-.1, 25000, .1, 0, .5, 20000
> > ar oscili kamp, kpitch, 1
> > out ar
> > endin
> >
> > 
> > 
> > f1 0 4096 10 1
> >
> > i1 0 3.5
> > i2 4 6
> > f0 10
> >
> > e
> >
> > 
> > 
> >
>
>