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)
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.
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)
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.
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.
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)
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
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.
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.
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.
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)
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
You could write code to parse MIDI events to Csound “i” statements and send them to Csound using csoundReadScore. Csound will handle all the scheduling as with any other score events.
While one could do that, if you have a midi stream you can just pass it to Csound via the API callbacks and let the engine deal with it.
No need for any further complication.
Prof. Victor Lazzarini
Maynooth University
Ireland
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.” )
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.
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.
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.
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)
