Re: [Csnd] [EXTERNAL] Re: [Csnd] Data buuffer between csound and host program ?

The Csound Mailinglist
1

As a newcomer you have to first assume it works (and it does). Then learn the system.

There is a midi buffer and it holds all the messages sent in. These are processed by Csound as they come in. Note on messages can instantiate, other messages are processed by other opcodes (cc, aft, pgm etc). The opcode midiin offers a generic receiving interface.

midiin will deliver all channel messages received. If you have a blocksize that is too large, then you should loop over the opcode to pick up all messages until the buffer is empty. That is what the manual says: “Normally (i.e., when no messages are pending) kstatus is zero, only when MIDI data are present in the MIDI IN buffer, is kstatus set to the type of the relevant messages.”

There are manual examples showing that for occasions when this might be relevant:

[

fluidControl
csound.com

](fluidControl)

This is exactly the case also for OSClisten.

Typical ksmps are 32, 64, which is around 1ms at 44.1k. While theoretically usb midi may deliver messages at a faster rate, the 3125 bytes/s gives us a limit of around 1ms per 3 byte midi message. Software midi of course may run faster, however there has been no indication from VST plugin users of any difficulties with Csound responding to midi from a DAW. Hadron for example was reported to have had 1/4 M downloads by 2019. You would think that if there was a problem, it would have been noted. Csound will respond to as many channel messages it receives.

You can run Csound with ksmps = 1 and pick up a message per sample if you wished. You can loop to oversample the midi read. That’s all of course an edge case if at all possible with current midi hardware and APIs.

If there is a bug, then a ticket is opened with a well documented demonstration and diagnostics. Then it is worked on and fixed.

No ifs or buts or wrong poorly informed assumptions.

Prof. Victor Lazzarini
Maynooth University
Ireland

2

Sorry, my purpose was not to claim any bug in csound. If there is a bug it is in my own understanding.

That fluidSynth-link showed how to read midi-in buffer to csound during the k-cycle. I suppose when the status-value (kst) is 0,
that means that the buffer is empty ?

That solved the midi-in → csound part.

Still having problems to implement the csound → java communication.
Here’s some kind of thought-example, how I would do it. If the loop would be done in java,
I would add something like this in the loop:

kDataBuffer[ j++ ] = kData; // kData represents some value of the midi-message

Now after the k-cycle is over I would read both kDataBuffer and j to java.
If e.g. 3 messages had arrived in the csound, then j=3 and java-code would know that
there are 3 elements in the vector.

But how to do that using csound functions and syntax ? Again it is quite clear that I don’t understand,
so no idea how to proceed.

–Risto

ti 7. toukok. 2024 klo 23.52 Victor Lazzarini (Victor.Lazzarini@mu.ie) kirjoitti:

As a newcomer you have to first assume it works (and it does). Then learn the system.

There is a midi buffer and it holds all the messages sent in. These are processed by Csound as they come in. Note on messages can instantiate, other messages are processed by other opcodes (cc, aft, pgm etc). The opcode midiin offers a generic receiving interface.

midiin will deliver all channel messages received. If you have a blocksize that is too large, then you should loop over the opcode to pick up all messages until the buffer is empty. That is what the manual says: “Normally (i.e., when no messages are pending) kstatus is zero, only when MIDI data are present in the MIDI IN buffer, is kstatus set to the type of the relevant messages.”

There are manual examples showing that for occasions when this might be relevant:

[

fluidControl
csound.com

](fluidControl)

This is exactly the case also for OSClisten.

Typical ksmps are 32, 64, which is around 1ms at 44.1k. While theoretically usb midi may deliver messages at a faster rate, the 3125 bytes/s gives us a limit of around 1ms per 3 byte midi message. Software midi of course may run faster, however there has been no indication from VST plugin users of any difficulties with Csound responding to midi from a DAW. Hadron for example was reported to have had 1/4 M downloads by 2019. You would think that if there was a problem, it would have been noted. Csound will respond to as many channel messages it receives.

You can run Csound with ksmps = 1 and pick up a message per sample if you wished. You can loop to oversample the midi read. That’s all of course an edge case if at all possible with current midi hardware and APIs.

If there is a bug, then a ticket is opened with a well documented demonstration and diagnostics. Then it is worked on and fixed.

No ifs or buts or wrong poorly informed assumptions.

Prof. Victor Lazzarini
Maynooth University
Ireland

Warning

This email originated from outside of Maynooth University’s Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe.

As I have earlier mentioned I’m a newcomer in csound-world. The functional logic is not that clear to me yet.

In the case of audio I understood that the a-variables are actually vectors that store ksmps-amount of values in them for each k-cycle
and then you can read the whole vector to host-UI at the same interval.
With my limited understanding I didn’t find a way how to do the same with midi-messages.
(from Csound Journal - Issue 10; An Overview of Csound Variable Types. … “k-type: These variables hold scalar values which are updated only once per control period.” )

–Risto

ti 7. toukok. 2024 klo 20.58 vlz (viclazzarini@gmail.com) kirjoitti:

You don’t get only single midi message in a k-cycle. You can have as many as you need. Why are you making all these absurd assumptions without knowing how the system works?
If there was such a ridiculous bottleneck, would you not think people could not notice it? It would be unusuable.

Prof. Victor Lazzarini
Maynooth University
Ireland

If i understand correctly midi-messages are read at k-rate ? How about if k-rate corresponds to e.g. 5ms ?
One midiCC-message could consist of 2 bytes, which corresponds to 16 bits.
The standard wired midi-connection speed is 31.25 kHz. This means that the required time for one midiCC-message is 16/31250 s = 0.000512 s.
This means that during 5ms time there could be place for almost 10 of these.
So if you read the messages at every 5ms, you could loose almost 9 of these, because you can read only (probably) the last one of those arrived during this 5ms period.

The situation is worse if the connection is e.g. Ethernet-midi, where the speed is something else.

–Risto

ti 7. toukok. 2024 klo 19.03 Victor Lazzarini (Victor.Lazzarini@mu.ie) kirjoitti:

Absolutely no idea what you are going on about. All frontends, hosts, whatever, using Csound work perfectly fine with midi and do not lose a single message. This has been the case since about 1992 when midi was first introduced to Csound.

If that weren’t the case we would have know by now over 30 years later.

Prof. Victor Lazzarini
Maynooth University
Ireland

Warning

This email originated from outside of Maynooth University’s Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe.

It seems that the idea of having enough time-resolution to catch every midi-message and keep the k-rate at some mild value, e.g. 5ms,
is not doable.
The stopper is already in Csound. If i try to do something like:

akStatus, akChan, akData1, akData2 midiin

, I get complaints from csound.

This is not allowed, because midiin accepts only k-variables.

If I use k-variables there, it means that I need to speed-up the k-rate to a value that is not practical for the host-UI program.

And actually I don’t know how fast rate would be needed if the connection is not a midi-cable but an Ethernet-midi connection instead.

–risto

ma 6. toukok. 2024 klo 22.03 Risto Kuusisto (rjzkuusisto@gmail.com) kirjoitti:

Ok I try to understand those.
But how about midi ? If I understand correctly, those mentioned ones are reserved for audio (float).

In the case of midi the usual keyboard-case would not require buffering. My case is related to a guitar effect pedal. When you change the patch, the device sends a program change number followed with the patch parameters as control change values. These I would like to get to the UI-host without loosing any of these.

–Risto

ma 6. toukok. 2024 klo 21.32 vlz <viclazzarini@gmail.com> kirjoitti:

yes, you can use an audio bus channel.
Access it using csoundGetChannelPtr()

[

Channels, Control and Events
csound.com

](Csound API: Channels, Control and Events)

audio channels handle vectors of ksmps samples

alternatively you can access the main IO buffers, spin and spout

[

Realtime Audio I/O
csound.com

](Csound API: Realtime Audio I/O)

[

Realtime Audio I/O
csound.com

](Csound API: Realtime Audio I/O)

these will give you vectors of ksmps frames,
interleaved.

Prof. Victor Lazzarini
Maynooth University
Ireland

Hello,

Piece by piece learning about communication between a host program (java/python/…) and csound.

The examples show the channel-method for that purpose. Anyway if i like to do something like this:

  • the host reads a vector of values e.g. at every 10ms => 480 values in a buffer if the sampling frequency is 48 kHz
  • the host is using those values increase real-time trend buffer in order to show the trend
  • during each 10 ms csound needs to fill some buffer with new new values for the next read from the host

I have seen only simple examples, where only a single value (or scalar), not a vector, is updated.
Can the vector-based communication also be implemented with csound itself and through csound-api ?

And what if the data is midi-messages instead of audio ? (= integer values)

–Risto

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

3

Can you explain if you are using Java to communicate with the audio IO drivers, or Csound. I’m unclear exactly who’s in charge of outputting audio. In my typical setup, I use an audio library to output samples to the sound card, and I use Csound to process those samples. If this is what you’re doing, then check out the Csound API MIDI callbacks. Have a look at how they work in Cabbage:

https://github.com/rorywalsh/cabbage/blob/develop/Source/Audio/Plugins/CsoundPluginProcessor.cpp#L1520-L1606

The read midi callback gets passed a pointer to Csound’s midi buffer. Cabbage fills this buffer with MIDI data from the host. I’m not sure this is helpful at all. If you are only providing a UI to Csound then things should be simpler.

4

Thanks for a hint.
My c+±understanding is not the best, but I guess you read the csound input midi-buffer directly? How does this show in the corresponding csound source-code ?

Or does it show there at all?

My case is for a guitar effect unit. When I change the patch there (with the included mechanical buttons or with an external midi-controller), the device sends midi:

  1. The corresponding program change number
  2. All related controllable patch parameters as midiCC-messages.
    (Typical parameters e.g. delay length, flanger frequency, pre-gain before amplifier simulator, post-gain, treble, bass, middle etc.)

I want to read all of those midi-messages into csound.
Then feed midiCC-values to java-UI as starting values for corresponding sliders.

After that it would be possible to move the sliders in the UI and write new values back to csound.
(future addition: to a file)

This part should be a typical case, only scalar values at a time and transformation of integer values to
suitable k-variable values in csound.

And from csound to midi-out.

In this first case csound would not touch the audio all.

–Risto

ke 8. toukok. 2024 klo 16.00 Rory Walsh (rorywalsh@ear.ie) kirjoitti:

Can you explain if you are using Java to communicate with the audio IO drivers, or Csound. I’m unclear exactly who’s in charge of outputting audio. In my typical setup, I use an audio library to output samples to the sound card, and I use Csound to process those samples. If this is what you’re doing, then check out the Csound API MIDI callbacks. Have a look at how they work in Cabbage:

https://github.com/rorywalsh/cabbage/blob/develop/Source/Audio/Plugins/CsoundPluginProcessor.cpp#L1520-L1606

The read midi callback gets passed a pointer to Csound’s midi buffer. Cabbage fills this buffer with MIDI data from the host. I’m not sure this is helpful at all. If you are only providing a UI to Csound then things should be simpler.

Sorry, my purpose was not to claim any bug in csound. If there is a bug it is in my own understanding.

That fluidSynth-link showed how to read midi-in buffer to csound during the k-cycle. I suppose when the status-value (kst) is 0,
that means that the buffer is empty ?

That solved the midi-in → csound part.

Still having problems to implement the csound → java communication.
Here’s some kind of thought-example, how I would do it. If the loop would be done in java,
I would add something like this in the loop:

kDataBuffer[ j++ ] = kData; // kData represents some value of the midi-message

Now after the k-cycle is over I would read both kDataBuffer and j to java.
If e.g. 3 messages had arrived in the csound, then j=3 and java-code would know that
there are 3 elements in the vector.

But how to do that using csound functions and syntax ? Again it is quite clear that I don’t understand,
so no idea how to proceed.

–Risto

ti 7. toukok. 2024 klo 23.52 Victor Lazzarini (Victor.Lazzarini@mu.ie) kirjoitti:

As a newcomer you have to first assume it works (and it does). Then learn the system.

There is a midi buffer and it holds all the messages sent in. These are processed by Csound as they come in. Note on messages can instantiate, other messages are processed by other opcodes (cc, aft, pgm etc). The opcode midiin offers a generic receiving interface.

midiin will deliver all channel messages received. If you have a blocksize that is too large, then you should loop over the opcode to pick up all messages until the buffer is empty. That is what the manual says: “Normally (i.e., when no messages are pending) kstatus is zero, only when MIDI data are present in the MIDI IN buffer, is kstatus set to the type of the relevant messages.”

There are manual examples showing that for occasions when this might be relevant:

[

fluidControl
csound.com

](fluidControl)

This is exactly the case also for OSClisten.

Typical ksmps are 32, 64, which is around 1ms at 44.1k. While theoretically usb midi may deliver messages at a faster rate, the 3125 bytes/s gives us a limit of around 1ms per 3 byte midi message. Software midi of course may run faster, however there has been no indication from VST plugin users of any difficulties with Csound responding to midi from a DAW. Hadron for example was reported to have had 1/4 M downloads by 2019. You would think that if there was a problem, it would have been noted. Csound will respond to as many channel messages it receives.

You can run Csound with ksmps = 1 and pick up a message per sample if you wished. You can loop to oversample the midi read. That’s all of course an edge case if at all possible with current midi hardware and APIs.

If there is a bug, then a ticket is opened with a well documented demonstration and diagnostics. Then it is worked on and fixed.

No ifs or buts or wrong poorly informed assumptions.

Prof. Victor Lazzarini
Maynooth University
Ireland

Warning

This email originated from outside of Maynooth University’s Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe.

As I have earlier mentioned I’m a newcomer in csound-world. The functional logic is not that clear to me yet.

In the case of audio I understood that the a-variables are actually vectors that store ksmps-amount of values in them for each k-cycle
and then you can read the whole vector to host-UI at the same interval.
With my limited understanding I didn’t find a way how to do the same with midi-messages.
(from Csound Journal - Issue 10; An Overview of Csound Variable Types. … “k-type: These variables hold scalar values which are updated only once per control period.” )

–Risto

ti 7. toukok. 2024 klo 20.58 vlz (viclazzarini@gmail.com) kirjoitti:

You don’t get only single midi message in a k-cycle. You can have as many as you need. Why are you making all these absurd assumptions without knowing how the system works?
If there was such a ridiculous bottleneck, would you not think people could not notice it? It would be unusuable.

Prof. Victor Lazzarini
Maynooth University
Ireland

If i understand correctly midi-messages are read at k-rate ? How about if k-rate corresponds to e.g. 5ms ?
One midiCC-message could consist of 2 bytes, which corresponds to 16 bits.
The standard wired midi-connection speed is 31.25 kHz. This means that the required time for one midiCC-message is 16/31250 s = 0.000512 s.
This means that during 5ms time there could be place for almost 10 of these.
So if you read the messages at every 5ms, you could loose almost 9 of these, because you can read only (probably) the last one of those arrived during this 5ms period.

The situation is worse if the connection is e.g. Ethernet-midi, where the speed is something else.

–Risto

ti 7. toukok. 2024 klo 19.03 Victor Lazzarini (Victor.Lazzarini@mu.ie) kirjoitti:

Absolutely no idea what you are going on about. All frontends, hosts, whatever, using Csound work perfectly fine with midi and do not lose a single message. This has been the case since about 1992 when midi was first introduced to Csound.

If that weren’t the case we would have know by now over 30 years later.

Prof. Victor Lazzarini
Maynooth University
Ireland

Warning

This email originated from outside of Maynooth University’s Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe.

It seems that the idea of having enough time-resolution to catch every midi-message and keep the k-rate at some mild value, e.g. 5ms,
is not doable.
The stopper is already in Csound. If i try to do something like:

akStatus, akChan, akData1, akData2 midiin

, I get complaints from csound.

This is not allowed, because midiin accepts only k-variables.

If I use k-variables there, it means that I need to speed-up the k-rate to a value that is not practical for the host-UI program.

And actually I don’t know how fast rate would be needed if the connection is not a midi-cable but an Ethernet-midi connection instead.

–risto

ma 6. toukok. 2024 klo 22.03 Risto Kuusisto (rjzkuusisto@gmail.com) kirjoitti:

Ok I try to understand those.
But how about midi ? If I understand correctly, those mentioned ones are reserved for audio (float).

In the case of midi the usual keyboard-case would not require buffering. My case is related to a guitar effect pedal. When you change the patch, the device sends a program change number followed with the patch parameters as control change values. These I would like to get to the UI-host without loosing any of these.

–Risto

ma 6. toukok. 2024 klo 21.32 vlz <viclazzarini@gmail.com> kirjoitti:

yes, you can use an audio bus channel.
Access it using csoundGetChannelPtr()

[

Channels, Control and Events
csound.com

](Csound API: Channels, Control and Events)

audio channels handle vectors of ksmps samples

alternatively you can access the main IO buffers, spin and spout

[

Realtime Audio I/O
csound.com

](Csound API: Realtime Audio I/O)

[

Realtime Audio I/O
csound.com

](Csound API: Realtime Audio I/O)

these will give you vectors of ksmps frames,
interleaved.

Prof. Victor Lazzarini
Maynooth University
Ireland

Hello,

Piece by piece learning about communication between a host program (java/python/…) and csound.

The examples show the channel-method for that purpose. Anyway if i like to do something like this:

  • the host reads a vector of values e.g. at every 10ms => 480 values in a buffer if the sampling frequency is 48 kHz
  • the host is using those values increase real-time trend buffer in order to show the trend
  • during each 10 ms csound needs to fill some buffer with new new values for the next read from the host

I have seen only simple examples, where only a single value (or scalar), not a vector, is updated.
Can the vector-based communication also be implemented with csound itself and through csound-api ?

And what if the data is midi-messages instead of audio ? (= integer values)

–Risto

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

5

I want to read all of those midi-messages into csound.

Then feed midiCC-values to java-UI as starting values for corresponding sliders.

This is trivial, no matter what language you use. When the MIDI messages come in from your device you can use the chnset opcode to send data to your host, which will then update the UI accordingly. You will need to run some kind of loop in your host app to pick up channel data.

After that it would be possible to move the sliders in the UI and write new values back to csound.

This will be done using the SetControlChannel() API method. The channel data you send there can be picked up in Csound using the chnget opcode. :+1:

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

6

Do you think that the speed requirement for the loop at the host side is not a problem
if it has to poll the chn-data all the time ?

Or is there any possibility to construct the loop in a way that it waits for the next chnset
on the csound side before the next round instead of running as fast as possible?
The messages come in bursts and there should be no reason to do anything until the next burst arrives.

–Risto

ke 8. toukok. 2024 klo 17.38 Rory Walsh (rorywalsh@ear.ie) kirjoitti:

I want to read all of those midi-messages into csound.

Then feed midiCC-values to java-UI as starting values for corresponding sliders.

This is trivial, no matter what language you use. When the MIDI messages come in from your device you can use the chnset opcode to send data to your host, which will then update the UI accordingly. You will need to run some kind of loop in your host app to pick up channel data.

After that it would be possible to move the sliders in the UI and write new values back to csound.

This will be done using the SetControlChannel() API method. The channel data you send there can be picked up in Csound using the chnget opcode. :+1:

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

7

It’s not a problem to poll for the data. You can do this on a background thread. There is a callback system too using the invalue/outvalue opcodes but in my experience polling works better. :+1:

8

Thanks, I will proceed according to this advice.

–Risto

to 9. toukok. 2024 klo 9.02 Rory Walsh <rorywalsh@ear.ie> kirjoitti:

It’s not a problem to poll for the data. You can do this on a background thread. There is a callback system too using the invalue/outvalue opcodes but in my experience polling works better. :+1:

Do you think that the speed requirement for the loop at the host side is not a problem
if it has to poll the chn-data all the time ?

Or is there any possibility to construct the loop in a way that it waits for the next chnset
on the csound side before the next round instead of running as fast as possible?
The messages come in bursts and there should be no reason to do anything until the next burst arrives.

–Risto

ke 8. toukok. 2024 klo 17.38 Rory Walsh (rorywalsh@ear.ie) kirjoitti:

I want to read all of those midi-messages into csound.

Then feed midiCC-values to java-UI as starting values for corresponding sliders.

This is trivial, no matter what language you use. When the MIDI messages come in from your device you can use the chnset opcode to send data to your host, which will then update the UI accordingly. You will need to run some kind of loop in your host app to pick up channel data.

After that it would be possible to move the sliders in the UI and write new values back to csound.

This will be done using the SetControlChannel() API method. The channel data you send there can be picked up in Csound using the chnget opcode. :+1:

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here