Istvan, what do you think needs to be done before a release?

I did have another suggestion which I will repeat, getting a Python binding to run Csound, create and edit scores, and so on into the non-CsoundVST version of csound 5. As I see it, the main obstacle to just moving CsoundVST into csound5's main library is the boost stuff in the algorithmic composition classes.

My questions are:

Do all the utilities run in 32 and 64 bits? I only care if they run inside Csound, I don't care about the standalone invocation.

Is there anything we can do to get FLTK working simultaneously for Ftable display and for FLTK widgets?



-----Original Message-----
From: Istvan Varga 
Sent: Sep 24, 2005 9:38 AM
To: csound-devel@lists.sourceforge.net
Subject: Re: [Cs-dev] Re: [Csnd] Csound 5 status

Other than the idea of integrating parts of the manual into the
source that I oppose, are there any suggested changes ?
It is really amazing that other than the idea of replacing CSOUND
with a C++ class, I still did not get a single comment on the API.
Minor but incompatible changes that clean up the interface should
be done now, before the release (which unfortunately seems to become
very unlikely this year, or maybe even the next year, as things
are now).


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel





-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

On Sep 24, 2005, at 11:47 AM, Michael Gogins wrote:

>
> Is there anything we can do to get FLTK working simultaneously for 
> Ftable display and for FLTK widgets?
>

Seems to work fine on OSX ... here's a screenshot of one of Art 
Hunkins' latest pieces:

http://www.csounds.com/akbari/AngelDervish.pdf

I'd also like to add that -g is really a drag when doing Scanned 
Synthesis!

-d is much better in that case ... but the FLTK looks nice for, say a 
demonstration in a classroom setting.


-David



-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Michael Gogins wrote:

> Istvan, what do you think needs to be done before a release?

I do not really have many ideas at this time, and that is one
of the reasons why I keep asking if anyone else does.
Currently, one unfinished project is the bus interface, but
it seems from the relative lack of comments that there is not
much interest or demand for it; so, I may consider removing it
for now, keeping only the two opcodes 'chnget' and 'chnset' for
private use by the orchestra, but no API functions or extra
features.
Another issue is replacing the use of rand() in various opcodes
with an API function that generates random numbers in a more
portable way, and without the problems associated with rand()
when used from multiple instances at the same time. This is not
really important, but it changes the output of the opcodes, so
is better done before the release.
It may also be worth to clean up the use of temporary files,
but this is a low priority issue too.
What is definitely to be done before a release is finishing
the API so that all incompatible changes (even if something
minor like renaming functions, changing the layout of structures,
etc.) are done now. As there are no comments on this issue,
it is tempting to leave everything as it is, but I am afraid
that people will start to complain when the interface is already
considered frozen and thus it is too late.
I still do not have plans on changes related to the "plugin
metadata" issue, because all the ideas so far are ones that I
either do not like, require too much changes, or are just not
sufficiently well defined to implement.

> I did have another suggestion which I will repeat, getting a
 > Python binding to run Csound, create and edit scores, and so on
 > into the non-CsoundVST version of csound 5. As I see it, the main
 > obstacle to just moving CsoundVST into csound5's main library is
 > the boost stuff in the algorithmic composition classes.

But why is it absolutely necessary to integrate CsoundVST into
libcsound ? I prefer having the library small and simple with as
few compile problems and external dependencies as possible;
CsoundVST - or anything else - can always just wrap the main
library.

> My questions are:
> 
> Do all the utilities run in 32 and 64 bits? I only care if they
 > run inside Csound, I don't care about the standalone invocation.

In most cases, it does not matter if the utilities are running from
csound (with -U) or as standalone, because almost all (with the
possible exception of some rarely used ones) have already been
converted to plugins. I think the more important utilities should
work using both 32 and 64 bit floats, but if you find one that
does not, then it should not be hard to fix the bug.

> Is there anything we can do to get FLTK working simultaneously
 > for Ftable display and for FLTK widgets?

I would prefer moving the FLTK table displays out of the engine
as well, leaving only the old ASCII and PostScript code as built-in.
It may be possible to integrate the display and widget code into
a single plugin that uses the API calls to register all the MakeGraph
and other functions, and having all FLTK stuff in one place again
might allow for easier fixing of the problems related to using
displays and widgets at the same time.
Also, not having FLTK displays in the main library means no
dependencies on FLTK or C++ at all, and the functions related to
FLTK locking could be removed from the API as well. I do not know,
though, if this is a problem for CsoundVST that also uses FLTK.


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Just to phone in my 2 cents.
I, for one, am very interested in getting signals in and out of csound,
for interfacing e.g. with python or some other external process.
Likewise, various apporaches to an internal signal bus, with alternatives for named and numbered channels are highly interesting. 
But I haven't found the time to sit down and really read and understand the implications of any of the recent additions and suggestions. 
Writing this just to say that there is interest, even if no replies, I simply did not know how to respond, yet.
Oeyvind 

> Currently, one unfinished project is the bus interface, but
> it seems from the relative lack of comments that there is not
> much interest or demand for it; so, I may consider removing it
> for now, keeping only the two opcodes 'chnget' and 'chnset' for
> private use by the orchestra, but no API functions or extra
> features.

Oeyvind Brandtsegg wrote:
> Just to phone in my 2 cents.
> I, for one, am very interested in getting signals in and out of csound,
> for interfacing e.g. with python or some other external process.
> Likewise, various apporaches to an internal signal bus, with alternatives for named and numbered channels are highly interesting. 
> But I haven't found the time to sit down and really read and understand the implications of any of the recent additions and suggestions. 
> Writing this just to say that there is interest, even if no replies, I simply did not know how to respond, yet.
> Oeyvind 


same here. I usually drive Csound from Smalltalk and Lisp.
so far I have been using sub-processes launched via shell commands; I 
have no idea what to suggest precisely that could help having a better 
integration, except that in both langages the Foreign Function Interface 
requires a .dll or a .so

could Csound easily be compiled as a dll for use via FFI ?


Stef


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

> I do not really have many ideas at this time, and that is one
> of the reasons why I keep asking if anyone else does.
> Currently, one unfinished project is the bus interface, but
> it seems from the relative lack of comments that there is not
> much interest or demand for it; so, I may consider removing it
> for now, keeping only the two opcodes 'chnget' and 'chnset' for
> private use by the orchestra, but no API functions or extra
> features.

As a user, I think that is a good plan. I would prefer to wait for a 
more complete bus interface that doesn't get rushed out the door.

> Another issue is replacing the use of rand() in various opcodes
> with an API function that generates random numbers in a more
> portable way, and without the problems associated with rand()
> when used from multiple instances at the same time. This is not
> really important, but it changes the output of the opcodes, so
> is better done before the release.

That sounds great too. Dealing with windows/linux rand incompatibilities 
is quite annoying to relatively new programmers so good random 
generators within csound would be very handy.

> It may also be worth to clean up the use of temporary files,
> but this is a low priority issue too.

I have a question on this, will csound5 gracefully handle no disk for 
temp files? Can it create them in memory? I am just thinking about use 
on live CDs. Csound5 will be included on the new Dyne:bolic II and 
Pure:Dyne live CDs.

> What is definitely to be done before a release is finishing
> the API so that all incompatible changes (even if something
> minor like renaming functions, changing the layout of structures,
> etc.) are done now. As there are no comments on this issue,
> it is tempting to leave everything as it is, but I am afraid
> that people will start to complain when the interface is already
> considered frozen and thus it is too late.

I agree there too. The api moves alot, would be great to have that 
stabilized as well as possible. When that happens, I would be happy to 
contribute my fairly simple api host example programs for the examples 
included with the release.

Thanks for listening,
Iain



-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

> same here. I usually drive Csound from Smalltalk and Lisp.
> so far I have been using sub-processes launched via shell commands; I 
> have no idea what to suggest precisely that could help having a better 
> integration, except that in both langages the Foreign Function Interface 
> requires a .dll or a .so
> 

Same here too. I also like the idea of being able to use both named and 
numbered signal paths, even more so I like the idea of being able to mix 
the two if that can be made possible. Being able to do:

	outsig	my_named_channel + koffset, blah, blah

would be very useful ( imaginary opcode, have not had the chance to dig 
into these new developments properly ).

Iain


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Hi List,

On Sep 25, 2005, at 6:35 AM, Istvan Varga wrote:
>> I did have another suggestion which I will repeat, getting a
> > Python binding to run Csound, create and edit scores, and so on
> > into the non-CsoundVST version of csound 5. As I see it, the main
> > obstacle to just moving CsoundVST into csound5's main library is
> > the boost stuff in the algorithmic composition classes.
>
> But why is it absolutely necessary to integrate CsoundVST into
> libcsound ? I prefer having the library small and simple with as
> few compile problems and external dependencies as possible;
> CsoundVST - or anything else - can always just wrap the main
> library.
>

Catching up on emails today, I feel that the response to this 
suggestion is VERY important and deserves reiteration.

For example for using Python, I prefer using Thomas Grill's py/pyext 
for Pd  in conjunction with csoundapi~ also in Pd.

http://grrrr.org/ext/

Of course this is by no means a "substitute" for CsoundVST, but allows 
a similar and possibly comparable function while maintaining a 
separateness between the small, efficient, and elegant CsoundLib and 
the Python interpreter.


-David



-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net