I have been attempting to build a Ubuntu environment under
virtualbox.  I am stuck trying to install a C++ compiler.  I was using
aptitude but cmake complains about no /usr/bin/c++
  What do I do to get one?

apt-get install g++ ?

Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy
Maynooth University
Ireland

> On 8 Aug 2016, at 19:10, jpff  wrote:
> 
> I have been attempting to build a Ubuntu environment under
> virtualbox.  I am stuck trying to install a C++ compiler.  I was using
> aptitude but cmake complains about no /usr/bin/c++
>  What do I do to get one?

Thank you bot; use of apt-get seems to have wored -- I have csound built 
on Ubutu now.  That is it runs "trapped.."

Main problems seem to be with VirtualBox, and screen utilisation (and I 
still dislike Ubutu)

On Mon, 8 Aug 2016, Victor Lazzarini wrote:

> apt-get install g++ ?
>
> Victor Lazzarini
> Dean of Arts, Celtic Studies, and Philosophy
> Maynooth University
> Ireland
>
>> On 8 Aug 2016, at 19:10, jpff  wrote:
>>
>> I have been attempting to build a Ubuntu environment under
>> virtualbox.  I am stuck trying to install a C++ compiler.  I was using
>> aptitude but cmake complains about no /usr/bin/c++
>>  What do I do to get one?
>> ==John ffitch

Hi Alex,

There are plans to do so and I was going to look into but have not had
the time as of yet.  I had done a research project a couple years ago
for getting Csound opcodes to work in Aura [1] which worked and
allowed for dynamically assembling a graph of opcodes together. This
worked fairly well and I had planned to base the new UGen API upon
this work.

There is an open issue [2] that was created to track this API work. A
number of other related issues possibly intertwine with this,
including the Node system I proposed, and [3] which discusses opcode
instances.

I think at this point it's a matter of just spending the time to
develop the API code.  The plan is to do this for Csound 7 and I will
most work on it in the features/parser3 branch.

I was planning to start working on Csound code again sometime this
month, but will try to bump it up in my schedule as you've expressed
an interest. One thing: what language or languages are you planning to
use?

Thanks,
steven



[1] - https://sourceforge.net/projects/aurart/
[2] - https://github.com/csound/csound/issues/407
[3] - https://github.com/csound/csound/issues/322

On Thu, Aug 11, 2016 at 8:53 PM, Alex Weiss  wrote:
> Hi list,
>
> I remember there was talk a while ago about extending the csound API in a
> way that would allow clients to inspect and modify the opcode graph of an
> instrument directly. I'm curious if that has been implemented yet or if
> there are any plans to do so.
>
> I mainly use csound as a synthesis engine and generating a textual
> representation of an instrument that then needs to be parsed and compiled
> always felt like an unnecessary (if not inefficient) step. It would be great
> to build instruments programmatically instead.
>
> Thanks,
> Alex

Hi Alex,

Thanks for mentioning C++.  The proposed UGen API is a bit low-level
but should be usable just fine with C++.  However, it might be easier
to use by generating wrapper classes.  I'll post here when I have
something at a testable state.

Thanks!
steven

On Thu, Aug 11, 2016 at 11:08 PM, Alex Weiss  wrote:
> Hi Steve,
>
> That's great to hear. I remember reading your paper on extending Aura a
> while back. Decoupling opcodes from the Csound engine sounds like another
> great feature in addition to creating UGen graphs.
>
> But please don't change your schedule on my account -- I'm very content to
> wait until Csound 7 comes out.
>
> FYI, all my programming work with Csound has been in C++.
>
> Thanks,
> Alex
>
>
> On Thu, Aug 11, 2016 at 6:54 PM Steven Yi  wrote:
>>
>> Hi Alex,
>>
>> There are plans to do so and I was going to look into but have not had
>> the time as of yet.  I had done a research project a couple years ago
>> for getting Csound opcodes to work in Aura [1] which worked and
>> allowed for dynamically assembling a graph of opcodes together. This
>> worked fairly well and I had planned to base the new UGen API upon
>> this work.
>>
>> There is an open issue [2] that was created to track this API work. A
>> number of other related issues possibly intertwine with this,
>> including the Node system I proposed, and [3] which discusses opcode
>> instances.
>>
>> I think at this point it's a matter of just spending the time to
>> develop the API code.  The plan is to do this for Csound 7 and I will
>> most work on it in the features/parser3 branch.
>>
>> I was planning to start working on Csound code again sometime this
>> month, but will try to bump it up in my schedule as you've expressed
>> an interest. One thing: what language or languages are you planning to
>> use?
>>
>> Thanks,
>> steven
>>
>>
>>
>> [1] - https://sourceforge.net/projects/aurart/
>> [2] - https://github.com/csound/csound/issues/407
>> [3] - https://github.com/csound/csound/issues/322
>>
>> On Thu, Aug 11, 2016 at 8:53 PM, Alex Weiss  wrote:
>> > Hi list,
>> >
>> > I remember there was talk a while ago about extending the csound API in
>> > a
>> > way that would allow clients to inspect and modify the opcode graph of
>> > an
>> > instrument directly. I'm curious if that has been implemented yet or if
>> > there are any plans to do so.
>> >
>> > I mainly use csound as a synthesis engine and generating a textual
>> > representation of an instrument that then needs to be parsed and
>> > compiled
>> > always felt like an unnecessary (if not inefficient) step. It would be
>> > great
>> > to build instruments programmatically instead.
>> >
>> > Thanks,
>> > Alex