Hi All,

I had the idea for a wait opcode today that I thought I would mention
here.  The idea is to allow writing Common Music style processes using
Csound instruments.  A possible code could look like:

instr Performer1
idur = 2
kindx = 0
knotenum = 60

while (kindx < 13) do
  event("i", 1, 0, dur, knotenum, 100)
  knotenum += 1
  wait(idur)
od
turnoff
endin

The idea is that when wait is hit, the instr would return and further
processing will do nothing until the wait time is over, then continue
on from after the wait.

The implementation would require a special wait processing opcode to
be inserted as the first instruction of the generated instrument
opcode chain.  The generated opcode chain would look something like:

wait_process wait_state
loopStart:
#b0 lt  kindx, 13
cggoto #b0, loopEnd
event("i", 1, 0, dur, knotenum, 100)
knotenum += 1
wait_start idur
waitEnd0:
goto loopStart
loopEnd:
turnoff

The wait_process would have memory for current wait states and target
labels. If there is no current wait, it would just proceed to the next
instruction.  If there is a wait state, the wait_process would check
elapsed time since the beginning of the wait and if not yet done, just
exit the instr by setting the next opds to NULL. If the time is
complete, it could set the next opcode to the wait target label.

I think with this implementation, the state of the instrument should
be correct before and after a wait state is found.  I do think the
wait opcode would be really bad to use if anyone tried to use it with
an audio producing instrument, but it would just be a case of good
documentation and appropriate warnings.

Thoughts and feedback welcome!
steven

p.s. - I have been thinking about this kind of problem in terms of my
system Pink.  For Pink, I was also thinking an extended "wait
(condition)" to do inter-process communication.  Processes could have
situations where they wait upon other processes to signal.  This
would, I believe, allow Lutoslawski-style aleatorism.  I have some
notes and am beginning to design the feature for Pink; if the above

I think it seems like a very useful opcode for control intruments,
generating events for other instruments, and other i- and k-rate
processing tasks.

2016-05-01 16:26 GMT+02:00 Steven Yi :
> Hi All,
>
> I had the idea for a wait opcode today that I thought I would mention
> here.  The idea is to allow writing Common Music style processes using
> Csound instruments.  A possible code could look like:
>
> instr Performer1
> idur = 2
> kindx = 0
> knotenum = 60
>
> while (kindx < 13) do
>   event("i", 1, 0, dur, knotenum, 100)
>   knotenum += 1
>   wait(idur)
> od
> turnoff
> endin
>
> The idea is that when wait is hit, the instr would return and further
> processing will do nothing until the wait time is over, then continue
> on from after the wait.
>
> The implementation would require a special wait processing opcode to
> be inserted as the first instruction of the generated instrument
> opcode chain.  The generated opcode chain would look something like:
>
> wait_process wait_state
> loopStart:
> #b0 lt  kindx, 13
> cggoto #b0, loopEnd
> event("i", 1, 0, dur, knotenum, 100)
> knotenum += 1
> wait_start idur
> waitEnd0:
> goto loopStart
> loopEnd:
> turnoff
>
> The wait_process would have memory for current wait states and target
> labels. If there is no current wait, it would just proceed to the next
> instruction.  If there is a wait state, the wait_process would check
> elapsed time since the beginning of the wait and if not yet done, just
> exit the instr by setting the next opds to NULL. If the time is
> complete, it could set the next opcode to the wait target label.
>
> I think with this implementation, the state of the instrument should
> be correct before and after a wait state is found.  I do think the
> wait opcode would be really bad to use if anyone tried to use it with
> an audio producing instrument, but it would just be a case of good
> documentation and appropriate warnings.
>
> Thoughts and feedback welcome!
> steven
>
> p.s. - I have been thinking about this kind of problem in terms of my
> system Pink.  For Pink, I was also thinking an extended "wait
> (condition)" to do inter-process communication.  Processes could have
> situations where they wait upon other processes to signal.  This
> would, I believe, allow Lutoslawski-style aleatorism.  I have some
> notes and am beginning to design the feature for Pink; if the above
> gets any traction, I can try to design similar features for Csound.



-- 

Oeyvind Brandtsegg
Professor of Music Technology
NTNU
7491 Trondheim
Norway
Cell: +47 92 203 205

http://www.partikkelaudio.com/
http://soundcloud.com/brandtsegg
http://flyndresang.no/

Very welcome idea!
I have missed it, too, and have done similar things with timout opcode with empty body under the timeout label. With wait it seems much more logical and straightforward.
Tarmo

Thanks all for feedback.  I have filed an issue to capture this idea:

https://github.com/csound/csound/issues/636

I'll plan to explore it in Pink first to get the idea sorted out, then
implement it for CS7.

On Sun, May 1, 2016 at 4:38 PM, Tarmo Johannes  wrote:
> Very welcome idea!
> I have missed it, too, and have done similar things with timout opcode with
> empty body under the timeout label. With wait it seems much more logical and
> straightforward.
> Tarmo
>
> 01.05.2016 23:09 kirjutas kuupäeval "Oeyvind Brandtsegg"
> :
>>
>> I think it seems like a very useful opcode for control intruments,
>> generating events for other instruments, and other i- and k-rate
>> processing tasks.
>>
>> 2016-05-01 16:26 GMT+02:00 Steven Yi :
>> > Hi All,
>> >
>> > I had the idea for a wait opcode today that I thought I would mention
>> > here.  The idea is to allow writing Common Music style processes using
>> > Csound instruments.  A possible code could look like:
>> >
>> > instr Performer1
>> > idur = 2
>> > kindx = 0
>> > knotenum = 60
>> >
>> > while (kindx < 13) do
>> >   event("i", 1, 0, dur, knotenum, 100)
>> >   knotenum += 1
>> >   wait(idur)
>> > od
>> > turnoff
>> > endin
>> >
>> > The idea is that when wait is hit, the instr would return and further
>> > processing will do nothing until the wait time is over, then continue
>> > on from after the wait.
>> >
>> > The implementation would require a special wait processing opcode to
>> > be inserted as the first instruction of the generated instrument
>> > opcode chain.  The generated opcode chain would look something like:
>> >
>> > wait_process wait_state
>> > loopStart:
>> > #b0 lt  kindx, 13
>> > cggoto #b0, loopEnd
>> > event("i", 1, 0, dur, knotenum, 100)
>> > knotenum += 1
>> > wait_start idur
>> > waitEnd0:
>> > goto loopStart
>> > loopEnd:
>> > turnoff
>> >
>> > The wait_process would have memory for current wait states and target
>> > labels. If there is no current wait, it would just proceed to the next
>> > instruction.  If there is a wait state, the wait_process would check
>> > elapsed time since the beginning of the wait and if not yet done, just
>> > exit the instr by setting the next opds to NULL. If the time is
>> > complete, it could set the next opcode to the wait target label.
>> >
>> > I think with this implementation, the state of the instrument should
>> > be correct before and after a wait state is found.  I do think the
>> > wait opcode would be really bad to use if anyone tried to use it with
>> > an audio producing instrument, but it would just be a case of good
>> > documentation and appropriate warnings.
>> >
>> > Thoughts and feedback welcome!
>> > steven
>> >
>> > p.s. - I have been thinking about this kind of problem in terms of my
>> > system Pink.  For Pink, I was also thinking an extended "wait
>> > (condition)" to do inter-process communication.  Processes could have
>> > situations where they wait upon other processes to signal.  This
>> > would, I believe, allow Lutoslawski-style aleatorism.  I have some
>> > notes and am beginning to design the feature for Pink; if the above
>> > gets any traction, I can try to design similar features for Csound.
>>
>>
>>
>> --
>>
>> Oeyvind Brandtsegg
>> Professor of Music Technology
>> NTNU
>> 7491 Trondheim
>> Norway
>> Cell: +47 92 203 205
>>
>> http://www.partikkelaudio.com/
>> http://soundcloud.com/brandtsegg
>> http://flyndresang.no/