Hi Andres,

That's a good question. :)  We should probably move anything that
could be publicly useful outside of csoundCore.h and into another
header, then include back into csoundCore.  This would probably go for
all of our types: MYFLT, STRINGDAT, SPECDAT, PVSDAT, ARRAYDAT.  It
would make sense to me that these would go into
csound_standard_types.h, as these are standard types.

I think in the future, for user-defined types, the information in
CS_TYPE would be enough to interrogate the data structure that is
returned in the void * data from channels.  We'd probably have a
USER_DEFINED_DAT or something.  It seems like this would all be enough
to interrogate channels for types and data structure types, yes?

Sidenote: we need to be careful about making this API I think to
minimize necessity to require changes later.  Also, we need to check
if this will all work for the language wrappers (Java, Python, etc.).

Do you have some example proposed code that we could use as the
starting point for documentation and help this conversation?

Thanks!
steven

On Sat, Apr 26, 2014 at 1:16 AM, Andres Cabrera  wrote:
> Hi (particularly Steven),
>
> I'm trying to figure out the best way to expose more data types in the
> debugger. I'm currently only passing the pointer to the data with the data
> type back to the host which then casts appropriately to get the data, but
> this won't work for other types like arrays, where the host would need to
> have available the ARRAYDAT struct which is currently defined in
> csoundCore.h. Maybe all these data type structs should be moved to the type
> system headers to allow their usage?
>
> Cheers,
> Andrés
>
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/li

With PVSDAT we would also need to expose AUXCH or maybe just a forward declaration will do.

========================
Dr Victor Lazzarini
Senior Lecturer
NUI Maynooth, Ireland
victor dot lazzarini at nuim dot ie




On 26 Apr 2014, at 18:44, Steven Yi  wrote:

> Hi Andres,
> 
> That's a good question. :)  We should probably move anything that
> could be publicly useful outside of csoundCore.h and into another
> header, then include back into csoundCore.  This would probably go for
> all of our types: MYFLT, STRINGDAT, SPECDAT, PVSDAT, ARRAYDAT.  It
> would make sense to me that these would go into
> csound_standard_types.h, as these are standard types.
> 
> I think in the future, for user-defined types, the information in
> CS_TYPE would be enough to interrogate the data structure that is
> returned in the void * data from channels.  We'd probably have a
> USER_DEFINED_DAT or something.  It seems like this would all be enough
> to interrogate channels for types and data structure types, yes?
> 
> Sidenote: we need to be careful about making this API I think to
> minimize necessity to require changes later.  Also, we need to check
> if this will all work for the language wrappers (Java, Python, etc.).
> 
> Do you have some example proposed code that we could use as the
> starting point for documentation and help this conversation?
> 
> Thanks!
> steven
> 
> On Sat, Apr 26, 2014 at 1:16 AM, Andres Cabrera  wrote:
>> Hi (particularly Steven),
>> 
>> I'm trying to figure out the best way to expose more data types in the
>> debugger. I'm currently only passing the pointer to the data with the data
>> type back to the host which then casts appropriately to get the data, but
>> this won't work for other types like arrays, where the host would need to
>> have available the ARRAYDAT struct which is currently defined in
>> csoundCore.h. Maybe all these data type structs should be moved to the type
>> system headers to allow their usage?
>> 
>> Cheers,
>> Andrés
>> 
>> ------------------------------------------------------------------------------
>> Start Your Social Network Today - Download eXo Platform
>> Build your Enterprise Intranet with eXo Platform Software
>> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
>> Get Started Now And Turn Your Intranet Into A Collaboration Platform
>> http://p.sf.net/sfu/ExoPlatform
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> 
> 
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

On the one hand, this would take a few days to sort out, but on the
other, it's sort of important too. Perhaps we could plan to ship 6.03
and do a 6.04 soon after that has this work.

For types and channels, maybe something like this would work:

CS_TYPE* csoundGetChannelType(CSOUND* csound, const char* channelName);

With the CS_TYPE, that'd give enough info for user-defined types as
well as built-in types.

On Sun, Apr 27, 2014 at 9:24 AM, Andres Cabrera  wrote:
> Hi,
>
>
> On Sat, Apr 26, 2014 at 10:44 AM, Steven Yi  wrote:
>>
>> Hi Andres,
>>
>> That's a good question. :)  We should probably move anything that
>> could be publicly useful outside of csoundCore.h and into another
>> header, then include back into csoundCore.  This would probably go for
>> all of our types: MYFLT, STRINGDAT, SPECDAT, PVSDAT, ARRAYDAT.  It
>> would make sense to me that these would go into
>> csound_standard_types.h, as these are standard types.
>
>
> Yes that was the way I pictured it.
> This seems like a really big change, that might not be good to make just
> prior to a release, but it also means that the debugger API will need to
> change as I can't currently rely on the host knowing about STRINGDAT. I
> think that's fine as the debugger is still in experimental stage.
>
>>
>> I think in the future, for user-defined types, the information in
>> CS_TYPE would be enough to interrogate the data structure that is
>> returned in the void * data from channels.  We'd probably have a
>> USER_DEFINED_DAT or something.  It seems like this would all be enough
>> to interrogate channels for types and data structure types, yes?
>
>
> What exactly do you mean. Like allowing user defined types too? I can't
> imagine how that would be handled from the host without knowing information
> about the type. But there must be a way as Python can do it...
>
>>
>> Sidenote: we need to be careful about making this API I think to
>> minimize necessity to require changes later.  Also, we need to check
>> if this will all work for the language wrappers (Java, Python, etc.).
>>
>
> Absolutely, another good reason to wait until after the release to look into
> this.
>
>>
>> Do you have some example proposed code that we could use as the
>> starting point for documentation and help this conversation?
>
>
> How would you imagine it? :)
>
>
>>
>> Thanks!
>> steven
>>
>> On Sat, Apr 26, 2014 at 1:16 AM, Andres Cabrera 
>> wrote:
>> > Hi (particularly Steven),
>> >
>> > I'm trying to figure out the best way to expose more data types in the
>> > debugger. I'm currently only passing the pointer to the data with the
>> > data
>> > type back to the host which then casts appropriately to get the data,
>> > but
>> > this won't work for other types like arrays, where the host would need
>> > to
>> > have available the ARRAYDAT struct which is currently defined in
>> > csoundCore.h. Maybe all these data type structs should be moved to the
>> > type
>> > system headers to allow their usage?
>> >
>> > Cheers,
>> > Andrés
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > Start Your Social Network Today - Download eXo Platform
>> > Build your Enterprise Intranet with eXo Platform Software
>> > Java Based Open Source Intranet - Social, Extensible, Cloud Ready
>> > Get Started Now And Turn Your Intranet Into A Collaboration Platform
>> > http://p.sf.net/sfu/ExoPlatform
>> > _______________________________________________
>> > Csound-devel mailing list
>> > Csound-devel@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/csound-devel
>> >
>>
>>
>> ------------------------------------------------------------------------------
>> Start Your Social Network Today - Download eXo Platform
>> Build your Enterprise Intranet with eXo Platform Software
>> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
>> Get Started Now And Turn Your Intranet Into A Collaboration Platform
>> http://p.sf.net/sfu/ExoPlatform
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/

Well we won't have to force using the new API functions.  The old ones
should still remain and could delegate to the new ones.  We can mark
them deprecated, then remove in Csound 7.

Otherwise, let's be sure to add unit tests for this work when we get
going on it, and schedule for 6.04.  We could file an issue in the
tracker and add a 6.04 milestone for tracking the work.

On Sun, Apr 27, 2014 at 5:23 PM, Andres Cabrera  wrote:
> I think that's a good idea. Since it will affect most front-ends, it's
> better to do it calmly and have time to test. It would be a significant API
> change that would merit a version increase, to make it clearer that old
> binaries won't work with the new version. But I remember there was a lot of
> pain of the last version bump... How could we minimize issues?
>
> Cheers,
> Andrés
>
>
> On Sun, Apr 27, 2014 at 7:12 AM, Steven Yi  wrote:
>>
>> On the one hand, this would take a few days to sort out, but on the
>> other, it's sort of important too. Perhaps we could plan to ship 6.03
>> and do a 6.04 soon after that has this work.
>>
>> For types and channels, maybe something like this would work:
>>
>> CS_TYPE* csoundGetChannelType(CSOUND* csound, const char* channelName);
>>
>> With the CS_TYPE, that'd give enough info for user-defined types as
>> well as built-in types.
>>
>> On Sun, Apr 27, 2014 at 9:24 AM, Andres Cabrera 
>> wrote:
>> > Hi,
>> >
>> >
>> > On Sat, Apr 26, 2014 at 10:44 AM, Steven Yi  wrote:
>> >>
>> >> Hi Andres,
>> >>
>> >> That's a good question. :)  We should probably move anything that
>> >> could be publicly useful outside of csoundCore.h and into another
>> >> header, then include back into csoundCore.  This would probably go for
>> >> all of our types: MYFLT, STRINGDAT, SPECDAT, PVSDAT, ARRAYDAT.  It
>> >> would make sense to me that these would go into
>> >> csound_standard_types.h, as these are standard types.
>> >
>> >
>> > Yes that was the way I pictured it.
>> > This seems like a really big change, that might not be good to make just
>> > prior to a release, but it also means that the debugger API will need to
>> > change as I can't currently rely on the host knowing about STRINGDAT. I
>> > think that's fine as the debugger is still in experimental stage.
>> >
>> >>
>> >> I think in the future, for user-defined types, the information in
>> >> CS_TYPE would be enough to interrogate the data structure that is
>> >> returned in the void * data from channels.  We'd probably have a
>> >> USER_DEFINED_DAT or something.  It seems like this would all be enough
>> >> to interrogate channels for types and data structure types, yes?
>> >
>> >
>> > What exactly do you mean. Like allowing user defined types too? I can't
>> > imagine how that would be handled from the host without knowing
>> > information
>> > about the type. But there must be a way as Python can do it...
>> >
>> >>
>> >> Sidenote: we need to be careful about making this API I think to
>> >> minimize necessity to require changes later.  Also, we need to check
>> >> if this will all work for the language wrappers (Java, Python, etc.).
>> >>
>> >
>> > Absolutely, another good reason to wait until after the release to look
>> > into
>> > this.
>> >
>> >>
>> >> Do you have some example proposed code that we could use as the
>> >> starting point for documentation and help this conversation?
>> >
>> >
>> > How would you imagine it? :)
>> >
>> >
>> >>
>> >> Thanks!
>> >> steven
>> >>
>> >> On Sat, Apr 26, 2014 at 1:16 AM, Andres Cabrera 
>> >> wrote:
>> >> > Hi (particularly Steven),
>> >> >
>> >> > I'm trying to figure out the best way to expose more data types in
>> >> > the
>> >> > debugger. I'm currently only passing the pointer to the data with the
>> >> > data
>> >> > type back to the host which then casts appropriately to get the data,
>> >> > but
>> >> > this won't work for other types like arrays, where the host would
>> >> > need
>> >> > to
>> >> > have available the ARRAYDAT struct which is currently defined in
>> >> > csoundCore.h. Maybe all these data type structs should be moved to
>> >> > the
>> >> > type
>> >> > system headers to allow their usage?
>> >> >
>> >> > Cheers,
>> >> > Andrés
>> >> >
>> >> >
>> >> >
>> >> > ------------------------------------------------------------------------------
>> >> > Start Your Social Network Today - Download eXo Platform
>> >> > Build your Enterprise Intranet with eXo Platform Software
>> >> > Java Based Open Source Intranet - Social, Extensible, Cloud Ready
>> >> > Get Started Now And Turn Your Intranet Into A Collaboration Platform
>> >> > http://p.sf.net/sfu/ExoPlatform
>> >> > _______________________________________________
>> >> > Csound-devel mailing list
>> >> > Csound-devel@lists.sourceforge.net
>> >> > https://lists.sourceforge.net/lists/listinfo/csound-devel
>> >> >
>> >>
>> >>
>> >>
>> >> ------------------------------------------------------------------------------
>> >> Start Your Social Network Today - Download eXo Platform
>> >> Build your Enterprise Intranet with eXo Platform Software
>> >> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
>> >> Get Started Now And Turn Your Intranet Into A Collaboration Platform
>> >> http://p.sf.net/sfu/ExoPlatform
>> >> _______________________________________________
>> >> Csound-devel mailing list
>> >> Csound-devel@lists.sourceforge.net
>> >> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> >
>> >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > Start Your Social Network Today - Download eXo Platform
>> > Build your Enterprise Intranet with eXo Platform Software
>> > Java Based Open Source Intranet - Social, Extensible, Cloud Ready
>> > Get Started Now And Turn Your Intranet Into A Collaboration Platform
>> > http://p.sf.net/sfu/ExoPlatform
>> > _______________________________________________
>> > Csound-devel mailing list
>> > Csound-devel@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/csound-devel
>> >
>>
>>
>> ------------------------------------------------------------------------------
>> Start Your Social Network Today - Download eXo Platform
>> Build your Enterprise Intranet with eXo Platform Software
>> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
>> Get Started Now And Turn Your Intranet Into A Collaboration Platform
>> http://p.sf.net/sfu/ExoPlatform
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.  Get 
unparalleled scalability from the best Selenium testing platform available.
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound

Hi Andres,

I've added issue 318:

https://github.com/csound/csound/issues/318

Please feel free to comment or subscribe to the issue (I think
commenting will automatically subscribe you to the issue).  I also
created a 6.04.0 milestone and added this to that.  Once 6.03.0 is out
the door, we should review the tickets list and come up with a list of
tasks we will want to have for 6.04 and organize them.

Thanks!
steven

On Mon, Apr 28, 2014 at 7:29 PM, Andres Cabrera  wrote:
> Hi Steven,
>
> I think that is a great idea, using a new set of API functions. For the
> callback mechanism, it would involve having some separate code and logic to
> handle the old mechanism and the new one, but apart from this, I think this
> is the best solution.
>
> Cheers,
> Andrés
>
>
> On Mon, Apr 28, 2014 at 9:22 AM, Steven Yi  wrote:
>>
>> Well we won't have to force using the new API functions.  The old ones
>> should still remain and could delegate to the new ones.  We can mark
>> them deprecated, then remove in Csound 7.
>>
>> Otherwise, let's be sure to add unit tests for this work when we get
>> going on it, and schedule for 6.04.  We could file an issue in the
>> tracker and add a 6.04 milestone for tracking the work.
>>
>> On Sun, Apr 27, 2014 at 5:23 PM, Andres Cabrera 
>> wrote:
>> > I think that's a good idea. Since it will affect most front-ends, it's
>> > better to do it calmly and have time to test. It would be a significant
>> > API
>> > change that would merit a version increase, to make it clearer that old
>> > binaries won't work with the new version. But I remember there was a lot
>> > of
>> > pain of the last version bump... How could we minimize issues?
>> >
>> > Cheers,
>> > Andrés
>> >
>> >
>> > On Sun, Apr 27, 2014 at 7:12 AM, Steven Yi  wrote:
>> >>
>> >> On the one hand, this would take a few days to sort out, but on the
>> >> other, it's sort of important too. Perhaps we could plan to ship 6.03
>> >> and do a 6.04 soon after that has this work.
>> >>
>> >> For types and channels, maybe something like this would work:
>> >>
>> >> CS_TYPE* csoundGetChannelType(CSOUND* csound, const char* channelName);
>> >>
>> >> With the CS_TYPE, that'd give enough info for user-defined types as
>> >> well as built-in types.
>> >>
>> >> On Sun, Apr 27, 2014 at 9:24 AM, Andres Cabrera 
>> >> wrote:
>> >> > Hi,
>> >> >
>> >> >
>> >> > On Sat, Apr 26, 2014 at 10:44 AM, Steven Yi 
>> >> > wrote:
>> >> >>
>> >> >> Hi Andres,
>> >> >>
>> >> >> That's a good question. :)  We should probably move anything that
>> >> >> could be publicly useful outside of csoundCore.h and into another
>> >> >> header, then include back into csoundCore.  This would probably go
>> >> >> for
>> >> >> all of our types: MYFLT, STRINGDAT, SPECDAT, PVSDAT, ARRAYDAT.  It
>> >> >> would make sense to me that these would go into
>> >> >> csound_standard_types.h, as these are standard types.
>> >> >
>> >> >
>> >> > Yes that was the way I pictured it.
>> >> > This seems like a really big change, that might not be good to make
>> >> > just
>> >> > prior to a release, but it also means that the debugger API will need
>> >> > to
>> >> > change as I can't currently rely on the host knowing about STRINGDAT.
>> >> > I
>> >> > think that's fine as the debugger is still in experimental stage.
>> >> >
>> >> >>
>> >> >> I think in the future, for user-defined types, the information in
>> >> >> CS_TYPE would be enough to interrogate the data structure that is
>> >> >> returned in the void * data from channels.  We'd probably have a
>> >> >> USER_DEFINED_DAT or something.  It seems like this would all be
>> >> >> enough
>> >> >> to interrogate channels for types and data structure types, yes?
>> >> >
>> >> >
>> >> > What exactly do you mean. Like allowing user defined types too? I
>> >> > can't
>> >> > imagine how that would be handled from the host without knowing
>> >> > information
>> >> > about the type. But there must be a way as Python can do it...
>> >> >
>> >> >>
>> >> >> Sidenote: we need to be careful about making this API I think to
>> >> >> minimize necessity to require changes later.  Also, we need to check
>> >> >> if this will all work for the language wrappers (Java, Python,
>> >> >> etc.).
>> >> >>
>> >> >
>> >> > Absolutely, another good reason to wait until after the release to
>> >> > look
>> >> > into
>> >> > this.
>> >> >
>> >> >>
>> >> >> Do you have some example proposed code that we could use as the
>> >> >> starting point for documentation and help this conversation?
>> >> >
>> >> >
>> >> > How would you imagine it? :)
>> >> >
>> >> >
>> >> >>
>> >> >> Thanks!
>> >> >> steven
>> >> >>
>> >> >> On Sat, Apr 26, 2014 at 1:16 AM, Andres Cabrera
>> >> >> 
>> >> >> wrote:
>> >> >> > Hi (particularly Steven),
>> >> >> >
>> >> >> > I'm trying to figure out the best way to expose more data types in
>> >> >> > the
>> >> >> > debugger. I'm currently only passing the pointer to the data with
>> >> >> > the
>> >> >> > data
>> >> >> > type back to the host which then casts appropriately to get the
>> >> >> > data,
>> >> >> > but
>> >> >> > this won't work for other types like arrays, where the host would
>> >> >> > need
>> >> >> > to
>> >> >> > have available the ARRAYDAT struct which is currently defined in
>> >> >> > csoundCore.h. Maybe all these data type structs should be moved to
>> >> >> > the
>> >> >> > type
>> >> >> > system headers to allow their usage?
>> >> >> >
>> >> >> > Cheers,
>> >> >> > Andrés
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > ------------------------------------------------------------------------------
>> >> >> > Start Your Social Network Today - Download eXo Platform
>> >> >> > Build your Enterprise Intranet with eXo Platform Software
>> >> >> > Java Based Open Source Intranet - Social, Extensible, Cloud Ready
>> >> >> > Get Started Now And Turn Your Intranet Into A Collaboration
>> >> >> > Platform
>> >> >> > http://p.sf.net/sfu/ExoPlatform
>> >> >> > _______________________________________________
>> >> >> > Csound-devel mailing list
>> >> >> > Csound-devel@lists.sourceforge.net
>> >> >> > https://lists.sourceforge.net/lists/listinfo/csound-devel
>> >> >> >
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >> ------------------------------------------------------------------------------
>> >> >> Start Your Social Network Today - Download eXo Platform
>> >> >> Build your Enterprise Intranet with eXo Platform Software
>> >> >> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
>> >> >> Get Started Now And Turn Your Intranet Into A Collaboration Platform
>> >> >> http://p.sf.net/sfu/ExoPlatform
>> >> >> _______________________________________________
>> >> >> Csound-devel mailing list
>> >> >> Csound-devel@lists.sourceforge.net
>> >> >> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > ------------------------------------------------------------------------------
>> >> > Start Your Social Network Today - Download eXo Platform
>> >> > Build your Enterprise Intranet with eXo Platform Software
>> >> > Java Based Open Source Intranet - Social, Extensible, Cloud Ready
>> >> > Get Started Now And Turn Your Intranet Into A Collaboration Platform
>> >> > http://p.sf.net/sfu/ExoPlatform
>> >> > _______________________________________________
>> >> > Csound-devel mailing list
>> >> > Csound-devel@lists.sourceforge.net
>> >> > https://lists.sourceforge.net/lists/listinfo/csound-devel
>> >> >
>> >>
>> >>
>> >>
>> >> ------------------------------------------------------------------------------
>> >> Start Your Social Network Today - Download eXo Platform
>> >> Build your Enterprise Intranet with eXo Platform Software
>> >> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
>> >> Get Started Now And Turn Your Intranet Into A Collaboration Platform
>> >> http://p.sf.net/sfu/ExoPlatform
>> >> _______________________________________________
>> >> Csound-devel mailing list
>> >> Csound-devel@lists.sourceforge.net
>> >> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> >
>> >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > Start Your Social Network Today - Download eXo Platform
>> > Build your Enterprise Intranet with eXo Platform Software
>> > Java Based Open Source Intranet - Social, Extensible, Cloud Ready
>> > Get Started Now And Turn Your Intranet Into A Collaboration Platform
>> > http://p.sf.net/sfu/ExoPlatform
>> > _______________________________________________
>> > Csound-devel mailing list
>> > Csound-devel@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/csound-devel
>> >
>>
>>
>> ------------------------------------------------------------------------------
>> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
>> Instantly run your Selenium tests across 300+ browser/OS combos.  Get
>> unparalleled scalability from the best Selenium testing platform
>> available.
>> Simple to use. Nothing to install. Get started now for free."
>> http://p.sf.net/sfu/SauceLabs
>>
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.  Get
> unparalleled scalability from the best Selenium testing platform available.
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.  Get 
unparalleled scalability from the best Selenium testing platform available.
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net