This is an experimental module that allows Csound5 to connect to the
JACK server. It appears to work, but there may be bugs and optimizations
may be needed for better performance.

Command line options
--------------------

To enable the JACK plugin, use this command line option:
   -+rtaudio=jack
Additionally, there are some command line options specific to JACK:
   -+jack_client=
     The client name used by Csound, defaults to 'csound5'.
   -+jack_inportname=
   -+jack_outportname=

     Name prefix of Csound JACK input/output ports; the default is
     'input' and 'output'. The actual port name is the channel number
     appended to the name prefix.
     Example: with the above default settings, a stereo orchestra will
     create these ports in full duplex operation:
       csound5:input1              (record left)
       csound5:input2              (record right)
       csound5:output1             (playback left)
       csound5:output2             (playback right)
   -+jack_sleep_time=
     Amount of time to wait before checking the buffer state again
     if it is full (playback) or empty (record). A higher value means
     worse latency and timing, but lower CPU usage.
     The default is 1000.

Connecting Csound to other JACK clients
---------------------------------------

By default, no connections are made (you need to use jack_connect);
however, the plugin can connect to ports specified as
  '-iadc:portname_prefix' or '-odac:portname_prefix'
portname_prefix is the full name of a port without a channel number,
such as 'alsa_pcm:capture_' (for -i adc), or 'alsa_pcm:playback_'
(for -o dac).

Notes on buffer sizes
---------------------

The -b option sets the period time in samples, and should be set to the
same value as the buffer size of JACK. -B is the total length of the
ring buffer. Both options must be power of two, and -b must be less
than -B.
If -iadc is used, ksmps should be set to an integer power of two, and
should be less than or equal to -b.

An example of buffer settings for low latency on a fast system:

   jackd -d alsa -P -r 48000 -p 64 -n 4 &
   csound -+rtaudio=jack -b 64 -B 256 [...]

with real time scheduling (as root):

   jackd -R -d alsa -P -r 48000 -p 64 -n 4 &
   csound --sched -+rtaudio=jack -b 64 -B 256 [...]

Note that the -p option for jackd is the same as -b for Csound.
To improve performance, use ksmps values like 32 and 64.

The sample rate of the orchestra must be the same as that of the JACK
server.



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

This is what I had in mind, when we discussed Jack extensively in the
csound list. I think it's a great addition, which I had in mind to do, if
no else got there first. I don't really know what all the fuss was with
people not really agreeing with the idea of such opcode.

Since Istvan is taking the Linux version development
lead, there is another possible suggestion as for another useful
addition.

That'd be a wrapper for LADSPA, so we can run csound as a ladspa
plugin, possibly with a FLTK interface. It's possible to do it in
the vein of CsoundVST and jcsound, with the API. There might be some 
constraints
that would have to be followed, like for instance  the number of  IO channels,
etc.. But I reckon is essentialy do-able and not a difficult thing, for that
matter (for someone with some time to look at it).

Another thing, which is not Linux specifically is to do a PD class like
Matt's MSP csound~ class. I know there is already a csound~ for PD,
but I'm not sure it uses the API (or if it uses as it should). I haven't seen
the code, but they're talking about pipes etc, which sounds as if they're
not using the API. The idea would be to do a cross-platform class that
would work on Linux. OS X and Windows.

Victor


At 14:40 10/02/2005, you wrote:
>This is an experimental module that allows Csound5 to connect to the
>JACK server. It appears to work, but there may be bugs and optimizations
>may be needed for better performance.
>
>Command line options
>--------------------
>
>To enable the JACK plugin, use this command line option:
>   -+rtaudio=jack
>Additionally, there are some command line options specific to JACK:
>   -+jack_client=
>     The client name used by Csound, defaults to 'csound5'.
>   -+jack_inportname=
>   -+jack_outportname=

>     Name prefix of Csound JACK input/output ports; the default is
>     'input' and 'output'. The actual port name is the channel number
>     appended to the name prefix.
>     Example: with the above default settings, a stereo orchestra will
>     create these ports in full duplex operation:
>       csound5:input1              (record left)
>       csound5:input2              (record right)
>       csound5:output1             (playback left)
>       csound5:output2             (playback right)
>   -+jack_sleep_time=
>     Amount of time to wait before checking the buffer state again
>     if it is full (playback) or empty (record). A higher value means
>     worse latency and timing, but lower CPU usage.
>     The default is 1000.
>
>Connecting Csound to other JACK clients
>---------------------------------------
>
>By default, no connections are made (you need to use jack_connect);
>however, the plugin can connect to ports specified as
>  '-iadc:portname_prefix' or '-odac:portname_prefix'
>portname_prefix is the full name of a port without a channel number,
>such as 'alsa_pcm:capture_' (for -i adc), or 'alsa_pcm:playback_'
>(for -o dac).
>
>Notes on buffer sizes
>---------------------
>
>The -b option sets the period time in samples, and should be set to the
>same value as the buffer size of JACK. -B is the total length of the
>ring buffer. Both options must be power of two, and -b must be less
>than -B.
>If -iadc is used, ksmps should be set to an integer power of two, and
>should be less than or equal to -b.
>
>An example of buffer settings for low latency on a fast system:
>
>   jackd -d alsa -P -r 48000 -p 64 -n 4 &
>   csound -+rtaudio=jack -b 64 -B 256 [...]
>
>with real time scheduling (as root):
>
>   jackd -R -d alsa -P -r 48000 -p 64 -n 4 &
>   csound --sched -+rtaudio=jack -b 64 -B 256 [...]
>
>Note that the -p option for jackd is the same as -b for Csound.
>To improve performance, use ksmps values like 32 and 64.
>
>The sample rate of the orchestra must be the same as that of the JACK
>server.
>
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>_______________________________________________
>Csound-devel mailing list
>Csound-devel@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/csound-devel

Victor Lazzarini
Music Technology Laboratory
Music Department
National University of Ireland, Maynooth 



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

If this is tackled, why not make it a dssi host, which can load LADSPA 
and dssi plugins? (all LADSPA plugins are valid dssi plugins)

I like the pd idea as well.

Andrés

Victor Lazzarini wrote:
> This is what I had in mind, when we discussed Jack extensively in the
> csound list. I think it's a great addition, which I had in mind to do, if
> no else got there first. I don't really know what all the fuss was with
> people not really agreeing with the idea of such opcode.
> 
> Since Istvan is taking the Linux version development
> lead, there is another possible suggestion as for another useful
> addition.
> 
> That'd be a wrapper for LADSPA, so we can run csound as a ladspa
> plugin, possibly with a FLTK interface. It's possible to do it in
> the vein of CsoundVST and jcsound, with the API. There might be some 
> constraints
> that would have to be followed, like for instance  the number of  IO 
> channels,
> etc.. But I reckon is essentialy do-able and not a difficult thing, for 
> that
> matter (for someone with some time to look at it).
> 
> Another thing, which is not Linux specifically is to do a PD class like
> Matt's MSP csound~ class. I know there is already a csound~ for PD,
> but I'm not sure it uses the API (or if it uses as it should). I haven't 
> seen
> the code, but they're talking about pipes etc, which sounds as if they're
> not using the API. The idea would be to do a cross-platform class that
> would work on Linux. OS X and Windows.
> 
> Victor
> 
> 
> At 14:40 10/02/2005, you wrote:
> 
>> This is an experimental module that allows Csound5 to connect to the
>> JACK server. It appears to work, but there may be bugs and optimizations
>> may be needed for better performance.
>>
>> Command line options
>> --------------------
>>
>> To enable the JACK plugin, use this command line option:
>>   -+rtaudio=jack
>> Additionally, there are some command line options specific to JACK:
>>   -+jack_client=
>>     The client name used by Csound, defaults to 'csound5'.
>>   -+jack_inportname=
>>   -+jack_outportname=

>>     Name prefix of Csound JACK input/output ports; the default is
>>     'input' and 'output'. The actual port name is the channel number
>>     appended to the name prefix.
>>     Example: with the above default settings, a stereo orchestra will
>>     create these ports in full duplex operation:
>>       csound5:input1              (record left)
>>       csound5:input2              (record right)
>>       csound5:output1             (playback left)
>>       csound5:output2             (playback right)
>>   -+jack_sleep_time=
>>     Amount of time to wait before checking the buffer state again
>>     if it is full (playback) or empty (record). A higher value means
>>     worse latency and timing, but lower CPU usage.
>>     The default is 1000.
>>
>> Connecting Csound to other JACK clients
>> ---------------------------------------
>>
>> By default, no connections are made (you need to use jack_connect);
>> however, the plugin can connect to ports specified as
>>  '-iadc:portname_prefix' or '-odac:portname_prefix'
>> portname_prefix is the full name of a port without a channel number,
>> such as 'alsa_pcm:capture_' (for -i adc), or 'alsa_pcm:playback_'
>> (for -o dac).
>>
>> Notes on buffer sizes
>> ---------------------
>>
>> The -b option sets the period time in samples, and should be set to the
>> same value as the buffer size of JACK. -B is the total length of the
>> ring buffer. Both options must be power of two, and -b must be less
>> than -B.
>> If -iadc is used, ksmps should be set to an integer power of two, and
>> should be less than or equal to -b.
>>
>> An example of buffer settings for low latency on a fast system:
>>
>>   jackd -d alsa -P -r 48000 -p 64 -n 4 &
>>   csound -+rtaudio=jack -b 64 -B 256 [...]
>>
>> with real time scheduling (as root):
>>
>>   jackd -R -d alsa -P -r 48000 -p 64 -n 4 &
>>   csound --sched -+rtaudio=jack -b 64 -B 256 [...]
>>
>> Note that the -p option for jackd is the same as -b for Csound.
>> To improve performance, use ksmps values like 32 and 64.
>>
>> The sample rate of the orchestra must be the same as that of the JACK
>> server.
>>
>>
>>
>> -------------------------------------------------------
>> SF email is sponsored by - The IT Product Guide
>> Read honest & candid reviews on hundreds of IT Products from real users.
>> Discover which products truly live up to the hype. Start reading now.
>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 
> 
> Victor Lazzarini
> Music Technology Laboratory
> Music Department
> National University of Ireland, Maynooth
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 
> 
> 


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

On Thu, 10 Feb 2005 15:45:11 +0000, Victor Lazzarini  
 wrote:

> Another thing, which is not Linux specifically is to do a PD class like
> Matt's MSP csound~ class. I know there is already a csound~ for PD,
> but I'm not sure it uses the API (or if it uses as it should). I haven't  
> seen
> the code, but they're talking about pipes etc, which sounds as if they're
> not using the API. The idea would be to do a cross-platform class that
> would work on Linux. OS X and Windows.
>
> Victor
>
That would be doable using the api.
The (dis)advantage of the pd-csound~ that allready exists is that it runs  
in a seperate process.
So if you run multiple instances that some of the time can overrun your  
processor power only the csound~ signals are affected. (of course I have  
the luxury of running an smp system and in that case using multiple  
processes distributes the load better as well, since the dsp loop is a  
single thread in pd (or jack for that matter)


Gerard


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net