I'd rather we kept everything within the libcsound as C and not C++.
Could you rewrite alwayson to C?

On Wed, Nov 27, 2013 at 1:10 PM, Michael Gogins
<michael.gogins@gmail.com> wrote:
> I would like to move the signal flow graph opcodes, which are implemented in
> C++ using the standard C++ library collections, into static linkage and into
> core Csound. Does anybody object? A number of people find these opcodes
> useful, and they make it vary simple to create self-contained instruments
> that can be swapped in and out of Csound orchestras in a very modular way.
>
> I'm not aware of any platforms that we build for at this time that lack the
> required compiler or library support.
>
> Regards,
> Mike
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
>

> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
> Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel

What exactly are the reasons why you prefer not to use C++ in libcsound?

Based on what I know, and I have considerable experience with both C and C++, I see no reason to rewrite the code in C. It works just fine the way it is, and rewriting it would simply be an unnecessary duplication of effort.

I am aware that the "core" of Csound has remained in C, but I do not see why. As far as I know, every platform on which Csound is currently supported has an adequate C++ compiler, and this particular set of opcodes does not use anything outside of the standard C++ library, except for OpenMP.

The code should still build "out of the box" on OS X (though it would not then support multi-threading). But I would be quite willing to rewrite the code to use plain pthreads and not OpenMP.

That said, although the opcodes were designed as a suite to enable the writing of completely self-contained instruments that work in a purely "plug and play" sort of way, it would be possible to move alwayson and ftgenonce to C because global variables could be used in place of the inlet, outlet, and connect opdoes as a means of routing signals between self-contained instrument definitions, even though that would be somewhat more awkward for the musician. In other words, just above each self-contained insdef, global global inlet and outlet opcodes, perhaps even arrays, would be defined using some sort of naming convention. Then a separate alwayson instrument, at the end of the orchestra, would take care of routing signals between these global variables.

So, if you are completely unwilling to admit even a particle of C++ into libcsound, I will rewrite ftgenonce and alwayson in C and we will still be able to get completely self-contained instrument definitions going for everybody.

Best,

Mike

-----------------------------------------------------

Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com
Michael dot Gogins at gmail dot com

On Sat, Nov 30, 2013 at 11:52 PM, Steven Yi <stevenyi@gmail.com> wrote:

I'd rather we kept everything within the libcsound as C and not C++.
Could you rewrite alwayson to C?

On Wed, Nov 27, 2013 at 1:10 PM, Michael Gogins
<michael.gogins@gmail.com> wrote:
> I would like to move the signal flow graph opcodes, which are implemented in
> C++ using the standard C++ library collections, into static linkage and into
> core Csound. Does anybody object? A number of people find these opcodes
> useful, and they make it vary simple to create self-contained instruments
> that can be swapped in and out of Csound orchestras in a very modular way.
>
> I'm not aware of any platforms that we build for at this time that lack the
> required compiler or library support.
>
> Regards,
> Mike
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
>

> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
> Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel

IMO, using C++ in the core isn't necessary.  It adds a compile time
dependency (C++ compiler) to the core, and adds further code knowledge
requirements (C++) to the base.  Also, programming in C++ has its own
mindset and approaches that don't necessarily map directly to C
practices. I would rather we just worked in a single language and
simplify things as much as possible for the core of csound.

I also don't think ftgenonce, alwayson, and the inlet/outlet opcodes
are going to solve the problem of self contained instruments.
Requiring a naming convention sounds problematic too.  But this is a
separate issue from C++ in the core of csound and I think we should
address the two separately.  I do think we need a solution for
self-contained instruments; I've already had one for a while in Blue,
but it leverages the program to handle ensuring encapsulation of all
resources and dependent UDO's, and it generates the mixer for the
user. I don't think alwayson is necessary since one can just call
event_i or schedule.  ftgenonce is handy but problematic, as there's
no guarantee that the user won't modify the shared table that is
returned, thus causing problems elsewhere.  (Of course one shouldn't,
but that's not guaranteed). inlet/outlet/connect I've criticized
before as it is working with definitions of instruments, rather than
instances of instruments.  Thus one can not define Reverb instrument
and use multiple instances of it with the inlet/outlet/connect
opcodes. In a system like SuperCollider, one might instantiate
multiple Synth instances of SynthDefs but tell them which channels of
the bus to read from/write to, and that's done at the instance level,
not the definition.

steven

On Sun, Dec 1, 2013 at 3:48 PM, Michael Gogins <michael.gogins@gmail.com> wrote:
> What exactly are the reasons why you prefer not to use C++ in libcsound?
>
> Based on what I know, and I have considerable experience with both C and
> C++, I see no reason to rewrite the code in C. It works just fine the way it
> is, and rewriting it would simply be an unnecessary duplication of effort.
>
> I am aware that the "core" of Csound has remained in C, but I do not see
> why. As far as I know, every platform on which Csound is currently supported
> has an adequate C++ compiler, and this particular set of opcodes does not
> use anything outside of the standard C++ library, except for OpenMP.
>
> The code should still build "out of the box" on OS X (though it would not
> then support multi-threading). But I would be quite willing to rewrite the
> code to use plain pthreads and not OpenMP.
>
> That said, although the opcodes were designed as a suite to enable the
> writing of completely self-contained instruments that work in a purely "plug
> and play" sort of way, it would be possible to move alwayson and ftgenonce
> to C because global variables could be used in place of the inlet, outlet,
> and connect opdoes as a means of routing signals between self-contained
> instrument definitions, even though that would be somewhat more awkward for
> the musician. In other words, just above each self-contained insdef, global
> global inlet and outlet opcodes, perhaps even arrays, would be defined using
> some sort of naming convention. Then a separate alwayson instrument, at the
> end of the orchestra, would take care of routing signals between these
> global variables.
>
> So, if you are completely unwilling to admit even a particle of C++ into
> libcsound, I will rewrite ftgenonce and alwayson in C and we will still be
> able to get completely self-contained instrument definitions going for
> everybody.
>
> Best,
> Mike
>
>
>
>
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
>
>
> On Sat, Nov 30, 2013 at 11:52 PM, Steven Yi <stevenyi@gmail.com> wrote:
>>
>> I'd rather we kept everything within the libcsound as C and not C++.
>> Could you rewrite alwayson to C?
>>
>> On Wed, Nov 27, 2013 at 1:10 PM, Michael Gogins
>> <michael.gogins@gmail.com> wrote:
>> > I would like to move the signal flow graph opcodes, which are
>> > implemented in
>> > C++ using the standard C++ library collections, into static linkage and
>> > into
>> > core Csound. Does anybody object? A number of people find these opcodes
>> > useful, and they make it vary simple to create self-contained
>> > instruments
>> > that can be swapped in and out of Csound orchestras in a very modular
>> > way.
>> >
>> > I'm not aware of any platforms that we build for at this time that lack
>> > the
>> > required compiler or library support.
>> >
>> > Regards,
>> > Mike
>> >
>> > -----------------------------------------------------
>> > Michael Gogins
>> > Irreducible Productions
>> > http://michaelgogins.tumblr.com
>> > Michael dot Gogins at gmail dot com
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > Rapidly troubleshoot problems before they affect your business. Most IT
>> > organizations don't have a clear picture of how application performance
>> > affects their revenue. With AppDynamics, you get 100% visibility into
>> > your
>> > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of
>> > AppDynamics
>> > Pro!
>> >
>> > http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
>> > _______________________________________________
>> > Csound-devel mailing list
>> > Csound-devel@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/csound-devel
>> >
>>
>>
>> ------------------------------------------------------------------------------
>> Rapidly troubleshoot problems before they affect your business. Most IT
>> organizations don't have a clear picture of how application performance
>> affects their revenue. With AppDynamics, you get 100% visibility into your
>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
>> Pro!
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
> Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel