I repeat my question whether the DSSI opcodes in Csound actually work
with DSSI plugins. Any response is most appreciated.

Regards,
Mike

-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel

Hi,

DSSI is a superset of LADSPA, so most of the work has been done, but
it's not finished, so DSSI don't work with Csound. I didn't know
enough at the time I worked on them to get them working.

Cheers,
Andrés

On Sat, Feb 27, 2010 at 2:29 PM, Michael Gogins
 wrote:
> I repeat my question whether the DSSI opcodes in Csound actually work
> with DSSI plugins. Any response is most appreciated.
>
> Regards,
> Mike
>
> --
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>



-- 


Andrés

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourcefor

Thanks for the update. The reason for asking was my search for a way
of using Aeolus from Csound.

What I am going to do is write a complete suite of Jack opcodes for
Csound. This will enable use of Aeolus, pianoteq, and so on from
Csound as if they were plugins. Aeolus does not have a DSSI interface.

The design of the proposed opcodes follows.

Regards,
Mike

/**
 * T H E   J A C K   O P C O D E S
 * Michael Gogins
 *
 * The Jack opcodes can be used to connect any number
 * of Csound instances, instruments, or user-defined
 * opcodes to any number of Jack ports
 * in any number of external Jack servers.
 *
 * Both audio and MIDI signal types are supported.
 *
 * The major purpose of the opcodes is to simplify
 * the use of external Jack synthesizers within Csound,
 * and also to simplify the use of Csound within
 * Jack-enabled hosts.
 *
 * O P C O D E S
 *
 * jackinit [[Sclientname], Servername]
 *
 * Initializes the Jack opcodes; must be called once in the
 * orchestra header.
 *
 * jackinfo
 *
 * Prints all Jack port names, types, and states at
 * the beginning of performance; may be called in the
 * orchestra header, after jackinit.
 *
 * kmode jackfreewheel kisfree
 *
 * Turns freewheeling mode on or off;
 * returns the prior state of freewheeling.
 *
 * asignal jackaudioin Sportname
 *
 * Receives an audio signal from the named sending port
 * (Csound creates a receiving port with an internal name).
 *
 * jackaudioout Sportname, asignal
 *
 * Sends an audio signal to the named receiving port
 * (Csound creates a sending port with an internal name).
 * Audio from multiple instances of the opcode sending
 * to the same port is summed before sending.
 *
 * kpending jackmidiinpending Sportname
 *
 * Returns true if any MIDI events are pending in the port.
 * This can be used to control a loop for reading any number
 * of events in the same kperiod.
 *
 * kstatus, kchannel, kdata1, kdata2 jackmidiin Sportname
 *
 * Receives one MIDI channel message from the port.
 *
 * jackmidiout Sportname, kstatus, kchannel, kdata1, kdata2
 *
 * Sends one MIDI channel message to the port. This can be called
 * any number of times in the same kperiod. Messages from multiple
 * instances of the opcode sending to the same port are collected
 * before sending.
 *
 * jacknoteout Sportname, ktime, kduration, kchannel, key, kvelocity
 *
 * Sends one note to the port. This can be called any number of times
 * in the same kperiod. The appropriate MIDI note off events are
 * generated and scheduled for later transmission. Notes from
 * multiple instances of the opcode sending to the same port are
 * collected before sending.
 *
 * I M P L E M E N T A T I O N
 *
 * Assumptions:
 *
 * 1. The Jack callback must run in a separate thread from Csound.
 * 2. Csound's ksmps must be equal to Jack's frames per period.
 * 3. These opcodes cannot be used in conjunction with Csound's
 *    -+rtaudio=jack command-line option.
 *
 * Order of processing:
 *
 * 1. The opcode init functions create a client, if one has not
 *    already been created for the running instance of Csound;
 *    the client is associated with the instance.
 * 2. The opcode init functions create and activate an internal port,
 *    if one has not already been created for that opcode;
 *    each port is associated with its instance of Csound;
 *    the internal port is then connected with the indicated
 *    external port.
 * 3. The Jack callbacks obtain all Jack buffers, then signal
 *    Csound to proceed, then wait.
 * 4. The opcode processing functions read from Jack output buffers,
 *    process audio, and write to Jack input buffers, then signal
 *    the Jack callbacks to proceed, then wait.
 * 5. The module deinitialization function deactivates and destroys
 *    all ports, then deactives and destroys the client, then
 *    erases all state.
 *
 * For this to work, each opcode processing function
 * or callback must increment a counter and actually signal
 * its lock only when all functions have finished their work.
 *
 * Also, signals that pass from Jack output ports,
 * through Csound processing, and to Jack input ports,
 * must be properly ordered by order of instrument and opcode declaration
 * within Csound.
 */


On Sat, Feb 27, 2010 at 12:15 PM, Andres Cabrera  wrote:
> Hi,
>
> DSSI is a superset of LADSPA, so most of the work has been done, but
> it's not finished, so DSSI don't work with Csound. I didn't know
> enough at the time I worked on them to get them working.
>
> Cheers,
> Andrés
>
> On Sat, Feb 27, 2010 at 2:29 PM, Michael Gogins
>  wrote:
>> I repeat my question whether the DSSI opcodes in Csound actually work
>> with DSSI plugins. Any response is most appreciated.
>>
>> Regards,
>> Mike
>>
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>>
>> ------------------------------------------------------------------------------
>> Download Intel® Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
>
>
> --
>
>
> Andrés
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>



-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I would suggest that instead of writing opcodes, you write a host that  
is a jack client. It will do the work better than having a bunch of  
opcodes.

Victor

On 27 Feb 2010, at 18:00, fons@kokkinizita.net wrote:

> On Sat, Feb 27, 2010 at 12:27:00PM -0500, Michael Gogins wrote:
>
>> What I am going to do is write a complete suite of Jack opcodes for
>> Csound. This will enable use of Aeolus, pianoteq, and so on from
>> Csound as if they were plugins. Aeolus does not have a DSSI  
>> interface.
>
> My first question is why ?
>
> Csound already allows reading or writing from or to
> a Jack port in an instrument. The only problem I see
> with the current implementation is that the number
> of inputs and outputs must be equal, which would
> lead to silly situations if you need e.g. 64 outs
> and just a few inputs. But there are solutions for
> that, and it's not a big issue anyway.
>
>> The design of the proposed opcodes follows.
>
>> * asignal jackaudioin Sportname
>> *
>> * Receives an audio signal from the named sending port
>> * (Csound creates a receiving port with an internal name).
>> *
>> * jackaudioout Sportname, asignal
>> *
>> * Sends an audio signal to the named receiving port
>> * (Csound creates a sending port with an internal name).
>
> If by 'named sending port' and 'named receiving port'
> you mean ports of other jack clients, this is a *very*
> bad idea. If you want to respect the normal way Jack
> is used then port creation/destruction and port con-
> nection/disconnection must be separate actions. Also
> take into account that your 'internal' ports will be
> visible externally if you want it or not.
>
> In general, Jack applications should just create their
> ports and ensure they have names that mean something
> to the user, in other words a name that indicates their
> funtion/use within the app that owns them. An app *may*
> connect its ports to other apps, but in general should
> not care where they are connected. This means you must
> allow the creation of ports that are not connected at
> all, and let the user take care of the connections.
>
>> * Audio from multiple instances of the opcode sending
>> * to the same port is summed before sending.
>
> If you mean the external destination this is not
> necessary, Jack does this anyway. You should just
> allow internal summing on your own output ports.
>
> Ciao,
>
> -- 
> FA
>
> O tu, che porte, correndo si ?
> E guerra e morte !
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

>  The only problem I see
> with the current implementation is that the number
> of inputs and outputs must be equal, which would
> lead to silly situations if you need e.g. 64 outs
> and just a few inputs. But there are solutions for
> that, and it's not a big issue anyway.
>
>

The code to have different in and out channel numbers is written and
waiting for 5.12 o settle before acyivating it

==John ff



------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Can't this be done with pd as well?

Best,

P


On 27 Feb 2010, at 18:12, Victor Lazzarini wrote:

> I would suggest that instead of writing opcodes, you write a host that
> is a jack client. It will do the work better than having a bunch of
> opcodes.
>
> Victor
>
> On 27 Feb 2010, at 18:00, fons@kokkinizita.net wrote:
>
>> On Sat, Feb 27, 2010 at 12:27:00PM -0500, Michael Gogins wrote:
>>
>>> What I am going to do is write a complete suite of Jack opcodes for
>>> Csound. This will enable use of Aeolus, pianoteq, and so on from
>>> Csound as if they were plugins. Aeolus does not have a DSSI
>>> interface.
>>
>> My first question is why ?
>>
>> Csound already allows reading or writing from or to
>> a Jack port in an instrument. The only problem I see
>> with the current implementation is that the number
>> of inputs and outputs must be equal, which would
>> lead to silly situations if you need e.g. 64 outs
>> and just a few inputs. But there are solutions for
>> that, and it's not a big issue anyway.
>>
>>> The design of the proposed opcodes follows.
>>
>>> * asignal jackaudioin Sportname
>>> *
>>> * Receives an audio signal from the named sending port
>>> * (Csound creates a receiving port with an internal name).
>>> *
>>> * jackaudioout Sportname, asignal
>>> *
>>> * Sends an audio signal to the named receiving port
>>> * (Csound creates a sending port with an internal name).
>>
>> If by 'named sending port' and 'named receiving port'
>> you mean ports of other jack clients, this is a *very*
>> bad idea. If you want to respect the normal way Jack
>> is used then port creation/destruction and port con-
>> nection/disconnection must be separate actions. Also
>> take into account that your 'internal' ports will be
>> visible externally if you want it or not.
>>
>> In general, Jack applications should just create their
>> ports and ensure they have names that mean something
>> to the user, in other words a name that indicates their
>> funtion/use within the app that owns them. An app *may*
>> connect its ports to other apps, but in general should
>> not care where they are connected. This means you must
>> allow the creation of ports that are not connected at
>> all, and let the user take care of the connections.
>>
>>> * Audio from multiple instances of the opcode sending
>>> * to the same port is summed before sending.
>>
>> If you mean the external destination this is not
>> necessary, Jack does this anyway. You should just
>> allow internal summing on your own output ports.
>>
>> Ciao,
>>
>> -- 
>> FA
>>
>> O tu, che porte, correndo si ?
>> E guerra e morte !
>>
>> ------------------------------------------------------------------------------
>> Download Intel® Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I appreciate all the comments but it is evident that nobody has understood my proposed use cases or that the opcodes would be more flexible and in practice easier to use than current csound.

I already understood about ports, connections and summing. The proposed opcodes would permit csound to automatically configure itself to work with other Jack applications and without external help.

MKG from cell phone

On Feb 27, 2010 1:18 PM, "Peiman Khosravi" <peimankhosravi@gmail.com> wrote:

Can't this be done with pd as well?

Best,

P

On 27 Feb 2010, at 18:12, Victor Lazzarini wrote:

> I would suggest that instead of writing opcod...

Starting jackd from csound would be optional, ditto for other clients.

That the session manager has been discussed as long as it has implies problems that, within the context of csound, my proposal should solve.

MKG from cell phone

On Feb 27, 2010 2:14 PM, <fons@kokkinizita.net> wrote:

On Sat, Feb 27, 2010 at 01:46:09PM -0500, Michael Gogins wrote:

> I appreciate all the comments but...

My experience in seven years use of Jack is that in
general apps that try 'to do everything themselves'
are creating more problems than they solve.

Are you also going to start jackd (if so, using which
configuration ?) and the other apps (same problem) from
within Csound ?

Doing this sort of thing is either the job of a session
manager (a thing being discussed heavily for some time),
or should be manual. Apps that 'go solo' are a big pain
in either case.

Ciao,

--
FA

O tu, che porte, correndo si ?
E guerra e morte !

---------------------------------...

How does it become non-portable? I don't see that it does that at all.

Regards,
Mike


On Sat, Feb 27, 2010 at 4:42 PM,   wrote:
> On Sat, Feb 27, 2010 at 02:41:43PM -0500, Michael Gogins wrote:
>
>> Starting jackd from csound would be optional, ditto for other clients.
>>
>> That the session manager has been discussed as long as it has implies
>> problems that, within the context of csound, my proposal should solve.
>
> >From that narrow perspective it may seem to solve
> some problems. The wider picture is very different.
>
> Using your new opcodes implies that the normal Jack
> interface (transparent to Csound code) is disabled.
> In other words, any Csound code using Jack in the way
> you propose becomes instantly non-portable.
>
> Ciao,
>
> --
> FA
>
> O tu, che porte, correndo si ?
> E guerra e morte !
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>



-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

OK, I think I see what you mean. You advise that Csound should not do
audio output or input in a platform-specific way or driver-specific
way in orchestra code, those options should be controlled from the
command line.

However, as far as I can see, Jack runs on Linux, Windows, and OS X.
So, Jack opcodes could certainly be portable in that sense.

I see the Jack opcodes as being in the same category as the existing
VST, LADSPA, or DSSI opcodes.

Regards,
Mike

On Sat, Feb 27, 2010 at 5:55 PM,   wrote:
> On Sat, Feb 27, 2010 at 05:34:34PM -0500, Michael Gogins wrote:
>
>> How does it become non-portable? I don't see that it does that at all.
>
> Because you use Jack-specific opcodes to do audio I/0.
>
> If you want portable Csound code it should use only
> generic (inJaterface agnostic) calls to do audio I/O.
>
> Anything specific to Jack (port names, connections,...)
> should be in the startup code only, where it is localised
> and easy to change/ignore/remove if necessary.
>
> Ciao,
>
> --
> FA
>
> O tu, che porte, correndo si ?
> E guerra e morte !
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>



-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Hi,

Thanks for trying. It's probably the GUI part of DSSI plugins that I
never finished.

Cheers,
Andrés

On Sat, Feb 27, 2010 at 6:12 PM, Rene Djack  wrote:
> Hi,
>
> Yes, it is working on UbuntuStudio 32b with csound5.12 cvs from Feb26.
> I just tested the included dssi4cs.csd included in the csound manual.
>
> On my system i have the env variable DSSI_PATH="/usr/lib/dssi"
>
> Best
> René
>
>
> 2010/2/27 Michael Gogins 
>>
>> I repeat my question whether the DSSI opcodes in Csound actually work
>> with DSSI plugins. Any response is most appreciated.
>>
>> Regards,
>> Mike
>>
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>
>



-- 


Andrés


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Hi,

I also think many of the options could be done not as opcodes, but as
shell commands wrapped in UDOs.

Cheers,
Andrés

On Sat, Feb 27, 2010 at 6:46 PM, Michael Gogins
 wrote:
> I appreciate all the comments but it is evident that nobody has understood
> my proposed use cases or that the opcodes would be more flexible and in
> practice easier to use than current csound.
>
> I already understood about ports, connections and summing. The proposed
> opcodes would permit csound to automatically configure itself to work with
> other Jack applications and without external help.
>
> MKG from cell phone
>
> On Feb 27, 2010 1:18 PM, "Peiman Khosravi"  wrote:
>
> Can't this be done with pd as well?
>
> Best,
>
> P
>
>
> On 27 Feb 2010, at 18:12, Victor Lazzarini wrote:
>
>> I would suggest that instead of writing opcod...
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>



-- 


Andrés

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/

Wow, Jack is now available for Windows! I never knew, although it
appears to be true, or at least in the works, from a quick search.
qjackctl is a JACK GUI program that I know works on Linux, but has
probably not been ported to Win/OSX (not sure, maybe it has) and it
has an option to store a group of desired connections, and then
implement them as soon as any of the ports in question come into
existence. It's kind of annoying that this functionality only exists
as part of a GUI, but I've gotten great use out of it when, for
instance, I wanted several programs to all connect automatically, but
at least two of them, like Csound, were not "on all the time" so to
speak. I don't know if this would come close to the use that you're
after, it's just something I happen to recall.

Regarding DSSI, I asked about using Csound as a DSSI plugin- not as a
host- when I first found out about CsLADSPA, and it seemed the
consensus was that LV2 was going to sweep the computer audio world
soon and make both LADSPA and DSSI obsolete. Seems it didn't live up
to the promise. Anyone have thoughts on that?

-Chuckk

On Sun, Feb 28, 2010 at 4:04 AM, Michael Gogins
 wrote:
> OK, I think I see what you mean. You advise that Csound should not do
> audio output or input in a platform-specific way or driver-specific
> way in orchestra code, those options should be controlled from the
> command line.
>
> However, as far as I can see, Jack runs on Linux, Windows, and OS X.
> So, Jack opcodes could certainly be portable in that sense.
>
> I see the Jack opcodes as being in the same category as the existing
> VST, LADSPA, or DSSI opcodes.
>
> Regards,
> Mike
>
> On Sat, Feb 27, 2010 at 5:55 PM,   wrote:
>> On Sat, Feb 27, 2010 at 05:34:34PM -0500, Michael Gogins wrote:
>>
>>> How does it become non-portable? I don't see that it does that at all.
>>
>> Because you use Jack-specific opcodes to do audio I/0.
>>
>> If you want portable Csound code it should use only
>> generic (inJaterface agnostic) calls to do audio I/O.
>>
>> Anything specific to Jack (port names, connections,...)
>> should be in the startup code only, where it is localised
>> and easy to change/ignore/remove if necessary.
>>
>> Ciao,
>>
>> --
>> FA
>>
>> O tu, che porte, correndo si ?
>> E guerra e morte !
>>
>> ------------------------------------------------------------------------------
>> Download Intel® Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
>
>
> --
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>



-- 
http://www.badmuthahubbard.com

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.so

Hi,

would you, Djack, or another volunteer, try out this example please? 
I just want to hear plate reverb on the sample "beats.wav" but was
unsuccesful.
I assume i have the ranges for dssictls allright.




-odac           -iadc     -d     ;;;RT audio I/O


  sr        =           44100
  kr        =           4410
  ksmps     =           10
  nchnls    =           2


gihandle dssiinit "plate_1423.so", 0, 1
gaout init  0

instr 1
print p4
dssiactivate gihandle, p4
endin

instr 2
ain1	diskin2 "beats.wav", 1
;outs	ain1, ain1

gaout = gaout+ain1
endin

instr 3
dssictls gihandle, 0, 5, 1	;  Port #0: Control Input: Reverb time - Range:
0.010000 -> 8.500000
dssictls gihandle, 1, .5, 1	;  Port #1: Control Input: Damping - Range:
0.000000 -> 1.000000
dssictls gihandle, 2, .5, 1 ;  Port #2: Control Input: Dry/wet mix - Range:
0.000000 -> 1.000000
;dssictls gihandle, 3, 1, 1 = imput port
;dssictls gihandle, 4, 1, 1 = output port
;dssictls gihandle, 5, 1, 1 = output port
endin

instr 4
;aout1,aout2 dssiaudio gihandle, ain1, ain2
aout1, aout2 dssiaudio gihandle, gaout	;get beats.wav
outs aout1,aout2

gaout = 0
endin





i 1 0 15 1
i 2 0 15
i 3 0 15
i 4 0 15

e





Djack wrote:
> 
> ladspa plugins are also working  =)
> 
> 
> 

Thanks Djack for trying!

i have tried several ladspa plugins. all with the goal of using them as
effects to a sound source. With only one of them i had some result. This is
the one:



-odac           ;-iadc     -d     ;;;RT audio I/O


  sr        =           44100
  kr        =           4410
  ksmps     =           10
  nchnls    =           2


;gihandle dssiinit "plate_1423.so", 0, 1
gihandle dssiinit "revdelay_1605.so", 0, 1
gaout init  0

instr 1
print p4
dssiactivate gihandle, p4
endin

instr 2
ain1	diskin2 "beats.wav", 1
;outs	ain1, ain1

gaout = gaout+ain1
endin

instr 3
dssictls gihandle, 2, 1.3, 1
;dssictls gihandle, 3, -10, 1	
dssictls gihandle, 4, 0, 1  
;dssictls gihandle, 5, .6, 1
dssictls gihandle, 6, .2, 1
dssictls gihandle, 5, .7, 1
endin

instr 4
;aout1,aout2 dssiaudio gihandle, ain1, ain2
aout1 dssiaudio gihandle, gaout	;get beats.wav
outs aout1,aout1

gaout = 0
endin



i 1 0 1 1
i 2 0 10
i 3 0 10
i 4 0 10
e



this information is copied from the output:
Number of Ports: 7
  Port #0: Audio Input: Input - Range: -Inf -> +Inf
  Port #1: Audio Output: Output - Range: -Inf -> +Inf
  Port #2: Control Input: Delay Time (s) - Range: 0.000000 -> 5.000000
  Port #3: Control Input: Dry Level (dB) - Range: -70.000000 -> 0.000000
  Port #4: Control Input: Wet Level (dB) - Range: -70.000000 -> 0.000000
  Port #5: Control Input: Feedback - Range: 0.000000 -> 1.000000
  Port #6: Control Input: Crossfade samples - Range: 0.000000 -> 5000.000000
Must run in realtime: NO
Is hard realtime capable: YES
Has activate() function: YES


Because this is the only one working a bit, but i am not in total control of
the DSSI system yet, i have several questions:
- should all ports be set with dssictls or, when a particular port is not
set explicitly, does it take on a default value?
- do the input and output port(s) have to be configured too (with dssictls)?
- is my example faulty?
- i see the statement: Is hard realtime capable: YES. Are these ladspa
plugins the ones i need for realtime use or will all the plugins be able to
run in realtime in Csound if my CPU permits?
- i do not understand this. What does this mean?

new alloc for instr 3:
DSSI4CS: Plugin 0 Located.
DSSI4CS: Port 2 multiplier (HintSampleRate): 1.
DSSI4CS: Connected Plugport 2 to output 0.
DSSI4CS: ArgMask: 0.
DSSI4CS: Plugin 0 Located.
DSSI4CS: Port 4 multiplier (HintSampleRate): 1.
DSSI4CS: Connected Plugport 4 to output 0.
DSSI4CS: ArgMask: 0.
DSSI4CS: Plugin 0 Located.
DSSI4CS: Port 6 multiplier (HintSampleRate): 1.
DSSI4CS: Connected Plugport 6 to output 0.
DSSI4CS: ArgMask: 0.
DSSI4CS: Plugin 0 Located.
DSSI4CS: Port 5 multiplier (HintSampleRate): 1.
DSSI4CS: Connected Plugport 5 to output 0.
DSSI4CS: ArgMask: 0.
new alloc for instr 4:
DSSI4CS: dssiaudio- 2 input args, 1 output args.
DSSI4CS: dssiaudio LocatePlugin # 0
DSSI4CS: Plugin 0 Located.
DSSI4CS: Port Index: 0
DSSI4CS: Connected Audio port: 0 to Input port : 0
DSSI4CS: Port Index: 1
DSSI4CS: Connected Audio Port: 1 to Output port: 1
DSSI4CS: Port Index: 2
DSSI4CS: Port Index: 3
DSSI4CS: Port Index: 4
DSSI4CS: Port Index: 5
DSSI4CS: Port Index: 6
DSSI4CS: Connected 1 audio input ports for: 'Reverse Delay (5s max)'
DSSI4CS: Connected 1 audio output ports for: 'Reverse Delay (5s max)'
DSSI4CS: Activate function called for: Reverse Delay (5s max)
B  0.000 ..  1.000 T  1.000 TT  1.000 M:  29312.0  29312.0
B  1.000 .. 10.000 T 10.000 TT 10.000 M:  48720.0  48720.0
	 number of samples out of range:       13       13

thanks for your time,
Menno

Hi,

I haven't used or tried these in a while, so I don't remember their
state and whether there are any issues...

On Fri, Jun 18, 2010 at 12:03 PM, menno  wrote:
>
> Because this is the only one working a bit, but i am not in total control of
> the DSSI system yet, i have several questions:
> - should all ports be set with dssictls or, when a particular port is not
> set explicitly, does it take on a default value?

They will take a default value but I'm not sure which. It probably
depends on each plugin.

> - do the input and output port(s) have to be configured too (with dssictls)?

I don't think so.

> - is my example faulty?

It looks OK....

> - i see the statement: Is hard realtime capable: YES. Are these ladspa
> plugins the ones i need for realtime use or will all the plugins be able to
> run in realtime in Csound if my CPU permits?

This is just something to let the host know that the plugin has been
programmed to be hard realtime capable. It has no real effect, but may
determine how the host treats the plugin. I think it has no effect in
Csound.

> - i do not understand this. What does this mean?
>
> new alloc for instr 3:
> DSSI4CS: Plugin 0 Located.
> DSSI4CS: Port 2 multiplier (HintSampleRate): 1.
> DSSI4CS: Connected Plugport 2 to output 0.
> DSSI4CS: ArgMask: 0.
> DSSI4CS: Plugin 0 Located.
> DSSI4CS: Port 4 multiplier (HintSampleRate): 1.
> DSSI4CS: Connected Plugport 4 to output 0.
> DSSI4CS: ArgMask: 0.
> DSSI4CS: Plugin 0 Located.
> DSSI4CS: Port 6 multiplier (HintSampleRate): 1.
> DSSI4CS: Connected Plugport 6 to output 0.
> DSSI4CS: ArgMask: 0.
> DSSI4CS: Plugin 0 Located.
> DSSI4CS: Port 5 multiplier (HintSampleRate): 1.
> DSSI4CS: Connected Plugport 5 to output 0.
> DSSI4CS: ArgMask: 0.
> new alloc for instr 4:
> DSSI4CS: dssiaudio- 2 input args, 1 output args.
> DSSI4CS: dssiaudio LocatePlugin # 0
> DSSI4CS: Plugin 0 Located.
> DSSI4CS: Port Index: 0
> DSSI4CS: Connected Audio port: 0 to Input port : 0
> DSSI4CS: Port Index: 1
> DSSI4CS: Connected Audio Port: 1 to Output port: 1
> DSSI4CS: Port Index: 2
> DSSI4CS: Port Index: 3
> DSSI4CS: Port Index: 4
> DSSI4CS: Port Index: 5
> DSSI4CS: Port Index: 6
> DSSI4CS: Connected 1 audio input ports for: 'Reverse Delay (5s max)'
> DSSI4CS: Connected 1 audio output ports for: 'Reverse Delay (5s max)'
> DSSI4CS: Activate function called for: Reverse Delay (5s max)

It's just telling explicitly what it's doing. When a port value change
is requested, it looks into the port, and checks the port hint, which
apparently does nothing in this case, as it multiplies by 1. I suspect
ArgMask tells whether the port is an input port, or an output port
(but I'm not 100% sure).
When instr 4  is called, you can see dssiaudio scanning all ports to
see which are audio ports, and then connecting them appropriately.

Something that calls my attention is that the activate function is
apparently being called after all the other stuff. Maybe that's the
issue?

Cheers,
Andrés


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Hi Andrés , 
i tried another example that works more or less, but not good enough. It
seems changing the values of dssictls have no effect, something is
definitely wrong. 
If you agree if would like to make a bug report of it in Csound with this
example below. This way the issue will not be forgotten - i assume you are
very busy with developing QuteCsound?
Let me know please

greetings
Menno



-odac         


  sr        =           44100
  kr        =           4410
  ksmps     =           10
  nchnls    =           2

gihandle dssiinit "g2reverb.so", 0, 1
gaout init  0

instr 1
;print p4
dssiactivate gihandle, 1
endin

instr 2
ain1	diskin2 "beats.wav", 1
;outs	ain1, ain1  ;no direct beat

gaout = gaout+ain1
endin

instr 3
; try this small room : dssictls gihandle, 4, 10, 1 	
dssictls gihandle, 4, 100, 1 ; big room 
dssictls gihandle, 5, 2, 1
dssictls gihandle, 6, .9, 1
dssictls gihandle, 9, 0, 1
dssictls gihandle, 10, .9, 1
endin

instr 4
;aout1,aout2 dssiaudio gihandle, ain1, ain2
aout1, aout2 dssiaudio gihandle, gaout, gaout	;get beats.wav and go stereo
out
outs aout1, aout2

gaout = 0
endin



i 1 0 6 
i 2 1 6
i 3 1 6
i 4 1 6
e



-- 
View this message in context: http://old.nabble.com/Csound-DSSI-tp27728340p28939692.html
Sent from the Csound - General mailing list archive at Nabble.com.



Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Hi all

i didn't notice until now but DSSI is working again!
Thank you for your work Andres.



-odac 


  sr        =           44100
  kr        =           4410
  ksmps     =           10
  nchnls    =           2


gihandle dssiinit "delayorama_1402.so", 0, 1
gaout init  0

instr 1
;print p4
dssiactivate gihandle, 1
endin

instr 2
ain1	diskin2 "beats.wav", 1
ain1 = ain1*.3
;outs	ain1, ain1

gaout = gaout+ain1
endin

instr 3
; try this small room : dssictls gihandle, 4, 10, 1 
dssictls gihandle, 1, 10, 1
dssictls gihandle, 2, 50, 1	
dssictls gihandle, 3, 10, 1 ; big room 
dssictls gihandle, 5, 1, 1
dssictls gihandle, 6, .5, 1
dssictls gihandle, 7, 100, 1
dssictls gihandle, 8, 3, 1
dssictls gihandle, 9, 60, 1
dssictls gihandle, 10, .5, 1
endin

instr 4

aout1 dssiaudio gihandle, gaout	;get beats.wav
outs aout1,aout1

gaout = 0
endin




i 1 0 10 
i 2 1 10
i 3 1 10
i 4 0 10

e

Hi Menno,

Good to know. I made some fixes, but they seemed to me not to have
fixed the issue, but they indeed have... I guess I might have not been
testing correctly, because your file now does work.

Cheers,
Andrés

On Sat, Aug 7, 2010 at 7:35 PM, menno  wrote:
>
> Hi all
>
> i didn't notice until now but DSSI is working again!
> Thank you for your work Andres.
>
> 
> 
> -odac
> 
> 
>  sr        =           44100
>  kr        =           4410
>  ksmps     =           10
>  nchnls    =           2
>
>
> gihandle dssiinit "delayorama_1402.so", 0, 1
> gaout init  0
>
> instr 1
> ;print p4
> dssiactivate gihandle, 1
> endin
>
> instr 2
> ain1    diskin2 "beats.wav", 1
> ain1 = ain1*.3
> ;outs   ain1, ain1
>
> gaout = gaout+ain1
> endin
>
> instr 3
> ; try this small room : dssictls gihandle, 4, 10, 1
> dssictls gihandle, 1, 10, 1
> dssictls gihandle, 2, 50, 1
> dssictls gihandle, 3, 10, 1 ; big room
> dssictls gihandle, 5, 1, 1
> dssictls gihandle, 6, .5, 1
> dssictls gihandle, 7, 100, 1
> dssictls gihandle, 8, 3, 1
> dssictls gihandle, 9, 60, 1
> dssictls gihandle, 10, .5, 1
> endin
>
> instr 4
>
> aout1 dssiaudio gihandle, gaout ;get beats.wav
> outs aout1,aout1
>
> gaout = 0
> endin
>
>
> 
> 
> i 1 0 10
> i 2 1 10
> i 3 1 10
> i 4 0 10
>
> e
> 
> 
> --
> View this message in context: http://csound.1045644.n5.nabble.com/Csound-DSSI-tp1110870p2267641.html
> Sent from the Csound - General mailing list archive at Nabble.com.
>
>
> Send bugs reports to the Sourceforge bug tracker
>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>
>



-- 


Andrés


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

i hope to upload examples of the DSSI opcodes for the manual today, now that
they seem to be working.
Thank you that you accidentally managed to get DSSI in Csound working again!

Menno