Hi All,

I added a proposal github issue for adding a Worker system to Csound 7:

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

The idea is to give users a clear way to do asynchronous processing
and work out ways to safely transfer data between two CSOUND
instances.  The WebWorker model seems like one that would work well
for our community and I would guess might be safer/easier to use than
dealing with user-defined threads and shared data read/write safety.

Would love to hear thoughts here or on the issue.

Thanks,
Steven

I am not familiar with the js model but I find the idea of defining a clear way to do async work really needed. At the moment something in that direction can be done when working in realtime, that does shift some tasks in the background. 

Would such a system surface for the user to define async tasks or would that be confined to the api?



On 22.03.23 16:08, Steven Yi  wrote:
> Hi All,
> 
> I added a proposal github issue for adding a Worker system to Csound 7:
> 
> https://github.com/csound/csound/issues/1700
> 
> The idea is to give users a clear way to do asynchronous processing
> and work out ways to safely transfer data between two CSOUND
> instances.  The WebWorker model seems like one that would work well
> for our community and I would guess might be safer/easier to use than
> dealing with user-defined threads and shared data read/write safety.
> 
> Would love to hear thoughts here or on the issue.
> 
> Thanks,
> Steven
> 

For reference, the MDN docs on Web Workers has an overview here:

https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API

My thought is that this is a system for users to write ORC code to
use.  With web workers, one defines the code that a worker runs and it
listens for messages to come in from the host. The worker can in turn
post messages back to the host. So a pseudo code might look something
like:

== worker.orc ==

sr=44100
ksmps=64
0dbfs=1

instr Listener
  ;; message data passed via channels?
  itype = chnget("msg:type")
  idata = chnget("msg:data")
  SfileName = chnget("msg:filename")

  ;; do something with data that generates an ftable
  iftab = ftgen(...)

  ;; send back to host, key and value
  post_ftable("ftable", iftab)

  ;; send other data back to host, key and value
  post_message("log", "Created ftable")
endin

// set message listener for this worker
message_listener("Listener")

== host.orc ==

...
table_loader:Worker = create_worker("./worker.orc") ;; creates worker
using worker.orc script
post_message("msg:type", 1, "msg:data", 10, "msg:filename",
"path/to/some/file.wav")

instr Listener
  key:S = chnget("msg:key")

  if(key == "table") then
    iftabnum = ftable_load(get_ftable(table_loader)) ;; get ftable in
last message in worker
  elseif (key == "log") then
    prints(get_string(table_loader)) ;; get string in last message in worker
  endif

endin

message_listener(table_loader, "Listener")

======

I suppose if messages come in on either side, it can create an
instance of the assigned instrument. We could maybe use channels
(though I'm not sure that's great?) or use some kind of
worker-specific opcodes for reading in data from the last message
posted when the instrument is initialized.

Kind of a quick rough draft idea on what the code might look like, any
suggestions appreciated!


On Wed, Mar 22, 2023 at 12:18 PM Eduardo Moguillansky
 wrote:
>
> I am not familiar with the js model but I find the idea of defining a clear way to do async work really needed. At the moment something in that direction can be done when working in realtime, that does shift some tasks in the background.
>
> Would such a system surface for the user to define async tasks or would that be confined to the api?
>
>
>
> On 22.03.23 16:08, Steven Yi  wrote:
> > Hi All,
> >
> > I added a proposal github issue for adding a Worker system to Csound 7:
> >
> > https://github.com/csound/csound/issues/1700
> >
> > The idea is to give users a clear way to do asynchronous processing
> > and work out ways to safely transfer data between two CSOUND
> > instances.  The WebWorker model seems like one that would work well
> > for our community and I would guess might be safer/easier to use than
> > dealing with user-defined threads and shared data read/write safety.
> >
> > Would love to hear thoughts here or on the issue.
> >
> > Thanks,
> > Steven
> >