Right now, with the ftgenonce opcode and the signal flow graph opcodes, 
instruments based on the following template can be freely shared with 
collisions or mismatches IF they also agree on the meanings of the pfields, 
or of a common set of initial pfields (illustrated below):

instr MyInstr
insno = p1
ionset = p2
iduration = p3
imidikey = p4
imidivelocity = p5
itable1 ftgenonce ....
...
itableN ftgenonce

; instrument processing code here...

outlet "ch1", aout1
outlet "ch2", aout2
...
outlet "chN", aoutN
endin

Connections from such instruments to outputs or effects are declared in the 
orchestra header. See the signal flow graph example in the Csound manual for 
a more complete explanation.

Regards,
Mike
----- Original Message ----- 
From: "Steven Yi" 
To: 
Sent: Saturday, January 16, 2010 12:32 PM
Subject: [Csnd] Re: Re: Re: Re: [announce] blue 2.0.0


Hi Andres,

Just catching up on older emails now.  blueShare itself is open in
that anyone can talk to the API (it uses xml-rpc, though I guess I
should considering moving to JSON sometime).  However, the big issue
is that what is stored in blueShare is just the XML-serialized version
of the different instrument classes and the effects objects.  These
then map to objects which other applications would need to have some
concept for and support.  I think the best way to think of what is in
blueShare and in blue is thinking of VST instruments and effects. Like
VST, blue instruments and effects are--when coded
correctly--completely self-contained and can be inserted into any
project and automatically link into the audio-signal flow graph
through the mixer.

The issue with trying to reuse the data in blueShare in say,
QuteCsound, is that I see diferences in the model for how interfaces
are used.  An application like QuteCsound, MacCsound, or using FLTK
widgets has a view where it's like you're building with Csound a
standalone audio application. The single main interface then is
reference-able by multiple csound instruments and there is no
encapsulation into reusable parts.  Not to say one method is better
than the other, just that the purposes are different, and there's sort
of a cognitive dissonance in how to share information.

As another example, blue also communicates to the Csound UDO
repository over xml-rpc and is able to download UDO's directly from
the website into the project.  This is possible because blue has a UDO
object that it can wrap the incoming UDO with and then handle as a
separate object.  In terms of other programs, unless they have this
abstraction, the best they can do is download the UDO and directly
insert the text into a CSD.

If there is a desire to create a share-able respository for Csound
programs, I think we'd have to come to some agreement on what we are
sharing.  Would it be an instrument? An ftable definition?  (Could be
useful if it could contain an attachment, so that we could store
things like strike data for physical models...).  If we come up with
the concepts of what to share, then we could look at creating a
CsoundShare site.

steven


On Sat, Jan 9, 2010 at 5:33 AM, Andres Cabrera  
wrote:
> Hi Steven,
>
> Nice work. Looks very polished.
>
> I've always thought that blue share could be a platform for
> collaboration even across frontends. What do you think of the widget
> format proposal I showed some time ago? Do you think it's worth trying
> to implement it to encourage collaboration in blue share?
>
> Cheers,
> Andrés
>
> On Fri, Jan 8, 2010 at 7:29 PM, Steven Yi  wrote:
>> Thanks Jason and everyone!
>>
>> I'm hoping to also "reboot" blueShare by making a full website that
>> will be both the home of blue (blue's new website) as well as
>> blueShare as part of it. Hopefully can make it more community
>> oriented, so things like seeing popularity of instruments/effects,
>> comments, etc. I'm working on a design document now for MIDI and
>> probably will try be a little more formal with how releases and things
>> get put together. Part of the future of blueShare I think will go
>> hand-in-hand with moving libraries from categories-based to tags-based
>> (or perhaps keeping categories and adding tags).
>>
>> There's a lot on my mind now but it's going to take some time to get
>> it all going. Hopefully we all benefit from it!
>>
>> Thanks!
>> steven
>>
>> On Fri, Jan 8, 2010 at 1:46 PM, Jason a  
>> wrote:
>>> AWESOME! just downloaded, gave it a good run-through and i'm impressed! 
>>> i
>>> installed it and whammo, it worked... no fiddling, no noodling with
>>> preferences, nothing! it seems a lot more stable in it's normal, 
>>> everyday
>>> functions too (button pushing, screen switching, etc). i can't wait to
>>> start composing with it. great job. big up to you Steven, and all of 
>>> your
>>> cohorts/minions/associates/assistants, great work.
>>>
>>> jAdams
>>>
>>> On Thu, Jan 7, 2010 at 10:36 PM, Steven Yi  wrote:
>>>>
>>>> Hi All,
>>>>
>>>> After a long hiatus for releases, I am happy to announce blue 2.0.0 is
>>>> now available at:
>>>>
>>>> http://www.csounds.com/stevenyi/blue
>>>>
>>>> (Note: the above site is old and will be updated for 2.1.0. The
>>>> download can also be retrieved from the sourceforge site at
>>>> http://sf.net/projects/bluemusic).
>>>>
>>>> The big change is that blue 2.0.0 has been rewritten to use the
>>>> Nebeans Rich-Client Platform. This has taken quite a bit of time but
>>>> I think the app has gained a lot of nice features in using the RCP
>>>> libraries, particularly a nicer window system that users can customize
>>>> the locations of windows of the app (i.e. move score side-by-side to
>>>> orchestra, detach orchestra into it's own window to pull to a separate
>>>> screen, etc.). Also, there a number of nice UI things in RCP that I
>>>> have started to take advantage of.
>>>>
>>>> This release is feature-equivalent to blue 0.125.0 and projects that
>>>> working 0.125.0 should work open up and work fine in blue 2.0.0. I am
>>>> going to be ramping up my time on developing blue and moving forward
>>>> with now with new feature development. Initial aims are to improve the
>>>> PatternObject and to work on MIDI input for 2.1.0, as well as going
>>>> through and taking care of issues in the bug and feature request
>>>> databases on SourceForge.
>>>>
>>>> Documentation was only partially updated for this release and most of
>>>> the documentation is still from 0.125.0. In reviewing the
>>>> documentation I have decided that a larger reorganization of the
>>>> documentation is necessary and this work has been scheduled for 2.1.0.
>>>> For any questions regarding 2.0.0, please either email the blue users
>>>> mailing list (preferred) or email me directly and I'll be happy to
>>>> answer questions.
>>>>
>>>> A note on installation: for this release and for the foreseeable
>>>> future, the application is now simply bundled in a zip file. Unzip
>>>> the file and go into the blue/bin folder and run either blue.exe or
>>>> the blue shell script to launch the application.
>>>>
>>>> Thank you to all of the blue users on on the blue mailing list who
>>>> have provided feedback during the 2.0.0 beta releases: you have helped
>>>> tremendously in helping to find bugs and make this release possible!
>>>>
>>>> Thanks an enjoy!
>>>> steven
>>>>
>>>> p.s. - Thank you to Brian Wong for contributing new pieces for the
>>>> examples folder! I know I have contacted a number of people for other
>>>> contributions and may have lost them in the time 2.0.0 was being
>>>> developed, my apologies! If you have a piece you would like to
>>>> contribute, please email me and I would love to add them to blue for
>>>> all users to study and enjoy!
>>>>
>>>> [CHANGE LOG]
>>>>
>>>> >Notes for 2.0.0 <
>>>> [released 2010.01.07]
>>>>
>>>> Steven
>>>> Yi-----------------------------------------------------------------------
>>>>
>>>> blue
>>>>
>>>> [new] - Converted application to use Netbeans Rich Client Platform to
>>>> take
>>>> advantage of new Window Manager and many libraries
>>>>
>>>> [new] - Added PulseAudio as driver option for Realtime Render settings
>>>> on
>>>> Linux
>>>>
>>>> [new] - Added pieces by Brian Wong to examples\pieces\brianWong folder
>>>>
>>>> [fix] - bug 2864419 - fixed importing multiline i- and f-statements
>>>> when
>>>> importing CSD or ORC/SCO; added multiline i-statment in score
>>>> parser
>>>>
>>>>
>>>> Send bugs reports to this list.
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body 
>>>> "unsubscribe
>>>> csound"
>>>
>>>
>>>
>>> --
>>> ciao,
>>> jAdams
>>>
>>>
>>>
>>>
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe 
>> csound"
>
>
>
> --
>
>
> Andrés
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe 
> csound"


Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe 
csound" 



Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

i think you mean without collisions, right?


Am 16.01.2010 um 19:03 schrieb michael.gogins@gmail.com:

> Right now, with the ftgenonce opcode and the signal flow graph  
> opcodes, instruments based on the following template can be freely  
> shared with collisions or mismatches IF they also agree on the  
> meanings of the pfields, or of a common set of initial pfields  
> (illustrated below):
>
> instr MyInstr
> insno = p1
> ionset = p2
> iduration = p3
> imidikey = p4
> imidivelocity = p5
> itable1 ftgenonce ....
> ...
> itableN ftgenonce
>
> ; instrument processing code here...
>
> outlet "ch1", aout1
> outlet "ch2", aout2
> ...
> outlet "chN", aoutN
> endin
>
> Connections from such instruments to outputs or effects are declared  
> in the orchestra header. See the signal flow graph example in the  
> Csound manual for a more complete explanation.
>
> Regards,
> Mike
> ----- Original Message ----- From: "Steven Yi" 
> To: 
> Sent: Saturday, January 16, 2010 12:32 PM
> Subject: [Csnd] Re: Re: Re: Re: [announce] blue 2.0.0
>
>
> Hi Andres,
>
> Just catching up on older emails now.  blueShare itself is open in
> that anyone can talk to the API (it uses xml-rpc, though I guess I
> should considering moving to JSON sometime).  However, the big issue
> is that what is stored in blueShare is just the XML-serialized version
> of the different instrument classes and the effects objects.  These
> then map to objects which other applications would need to have some
> concept for and support.  I think the best way to think of what is in
> blueShare and in blue is thinking of VST instruments and effects. Like
> VST, blue instruments and effects are--when coded
> correctly--completely self-contained and can be inserted into any
> project and automatically link into the audio-signal flow graph
> through the mixer.
>
> The issue with trying to reuse the data in blueShare in say,
> QuteCsound, is that I see diferences in the model for how interfaces
> are used.  An application like QuteCsound, MacCsound, or using FLTK
> widgets has a view where it's like you're building with Csound a
> standalone audio application. The single main interface then is
> reference-able by multiple csound instruments and there is no
> encapsulation into reusable parts.  Not to say one method is better
> than the other, just that the purposes are different, and there's sort
> of a cognitive dissonance in how to share information.
>
> As another example, blue also communicates to the Csound UDO
> repository over xml-rpc and is able to download UDO's directly from
> the website into the project.  This is possible because blue has a UDO
> object that it can wrap the incoming UDO with and then handle as a
> separate object.  In terms of other programs, unless they have this
> abstraction, the best they can do is download the UDO and directly
> insert the text into a CSD.
>
> If there is a desire to create a share-able respository for Csound
> programs, I think we'd have to come to some agreement on what we are
> sharing.  Would it be an instrument? An ftable definition?  (Could be
> useful if it could contain an attachment, so that we could store
> things like strike data for physical models...).  If we come up with
> the concepts of what to share, then we could look at creating a
> CsoundShare site.
>
> steven
>
>
> On Sat, Jan 9, 2010 at 5:33 AM, Andres Cabrera  
>  wrote:
>> Hi Steven,
>>
>> Nice work. Looks very polished.
>>
>> I've always thought that blue share could be a platform for
>> collaboration even across frontends. What do you think of the widget
>> format proposal I showed some time ago? Do you think it's worth  
>> trying
>> to implement it to encourage collaboration in blue share?
>>
>> Cheers,
>> Andrés
>>
>> On Fri, Jan 8, 2010 at 7:29 PM, Steven Yi  wrote:
>>> Thanks Jason and everyone!
>>>
>>> I'm hoping to also "reboot" blueShare by making a full website that
>>> will be both the home of blue (blue's new website) as well as
>>> blueShare as part of it. Hopefully can make it more community
>>> oriented, so things like seeing popularity of instruments/effects,
>>> comments, etc. I'm working on a design document now for MIDI and
>>> probably will try be a little more formal with how releases and  
>>> things
>>> get put together. Part of the future of blueShare I think will go
>>> hand-in-hand with moving libraries from categories-based to tags- 
>>> based
>>> (or perhaps keeping categories and adding tags).
>>>
>>> There's a lot on my mind now but it's going to take some time to get
>>> it all going. Hopefully we all benefit from it!
>>>
>>> Thanks!
>>> steven
>>>
>>> On Fri, Jan 8, 2010 at 1:46 PM, Jason a  
>>>  wrote:
>>>> AWESOME! just downloaded, gave it a good run-through and i'm  
>>>> impressed! i
>>>> installed it and whammo, it worked... no fiddling, no noodling with
>>>> preferences, nothing! it seems a lot more stable in it's normal,  
>>>> everyday
>>>> functions too (button pushing, screen switching, etc). i can't  
>>>> wait to
>>>> start composing with it. great job. big up to you Steven, and all  
>>>> of your
>>>> cohorts/minions/associates/assistants, great work.
>>>>
>>>> jAdams
>>>>
>>>> On Thu, Jan 7, 2010 at 10:36 PM, Steven Yi   
>>>> wrote:
>>>>>
>>>>> Hi All,
>>>>>
>>>>> After a long hiatus for releases, I am happy to announce blue  
>>>>> 2.0.0 is
>>>>> now available at:
>>>>>
>>>>> http://www.csounds.com/stevenyi/blue
>>>>>
>>>>> (Note: the above site is old and will be updated for 2.1.0. The
>>>>> download can also be retrieved from the sourceforge site at
>>>>> http://sf.net/projects/bluemusic).
>>>>>
>>>>> The big change is that blue 2.0.0 has been rewritten to use the
>>>>> Nebeans Rich-Client Platform. This has taken quite a bit of time  
>>>>> but
>>>>> I think the app has gained a lot of nice features in using the RCP
>>>>> libraries, particularly a nicer window system that users can  
>>>>> customize
>>>>> the locations of windows of the app (i.e. move score side-by- 
>>>>> side to
>>>>> orchestra, detach orchestra into it's own window to pull to a  
>>>>> separate
>>>>> screen, etc.). Also, there a number of nice UI things in RCP  
>>>>> that I
>>>>> have started to take advantage of.
>>>>>
>>>>> This release is feature-equivalent to blue 0.125.0 and projects  
>>>>> that
>>>>> working 0.125.0 should work open up and work fine in blue 2.0.0.  
>>>>> I am
>>>>> going to be ramping up my time on developing blue and moving  
>>>>> forward
>>>>> with now with new feature development. Initial aims are to  
>>>>> improve the
>>>>> PatternObject and to work on MIDI input for 2.1.0, as well as  
>>>>> going
>>>>> through and taking care of issues in the bug and feature request
>>>>> databases on SourceForge.
>>>>>
>>>>> Documentation was only partially updated for this release and  
>>>>> most of
>>>>> the documentation is still from 0.125.0. In reviewing the
>>>>> documentation I have decided that a larger reorganization of the
>>>>> documentation is necessary and this work has been scheduled for  
>>>>> 2.1.0.
>>>>> For any questions regarding 2.0.0, please either email the blue  
>>>>> users
>>>>> mailing list (preferred) or email me directly and I'll be happy to
>>>>> answer questions.
>>>>>
>>>>> A note on installation: for this release and for the foreseeable
>>>>> future, the application is now simply bundled in a zip file. Unzip
>>>>> the file and go into the blue/bin folder and run either blue.exe  
>>>>> or
>>>>> the blue shell script to launch the application.
>>>>>
>>>>> Thank you to all of the blue users on on the blue mailing list who
>>>>> have provided feedback during the 2.0.0 beta releases: you have  
>>>>> helped
>>>>> tremendously in helping to find bugs and make this release  
>>>>> possible!
>>>>>
>>>>> Thanks an enjoy!
>>>>> steven
>>>>>
>>>>> p.s. - Thank you to Brian Wong for contributing new pieces for the
>>>>> examples folder! I know I have contacted a number of people for  
>>>>> other
>>>>> contributions and may have lost them in the time 2.0.0 was being
>>>>> developed, my apologies! If you have a piece you would like to
>>>>> contribute, please email me and I would love to add them to blue  
>>>>> for
>>>>> all users to study and enjoy!
>>>>>
>>>>> [CHANGE LOG]
>>>>>
>>>>> >Notes for 2.0.0 <
>>>>> [released 2010.01.07]
>>>>>
>>>>> Steven
>>>>> Yi 
>>>>> -----------------------------------------------------------------------
>>>>>
>>>>> blue
>>>>>
>>>>> [new] - Converted application to use Netbeans Rich Client  
>>>>> Platform to
>>>>> take
>>>>> advantage of new Window Manager and many libraries
>>>>>
>>>>> [new] - Added PulseAudio as driver option for Realtime Render  
>>>>> settings
>>>>> on
>>>>> Linux
>>>>>
>>>>> [new] - Added pieces by Brian Wong to examples\pieces\brianWong  
>>>>> folder
>>>>>
>>>>> [fix] - bug 2864419 - fixed importing multiline i- and f- 
>>>>> statements
>>>>> when
>>>>> importing CSD or ORC/SCO; added multiline i-statment in score
>>>>> parser
>>>>>
>>>>>
>>>>> Send bugs reports to this list.
>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>>>>> "unsubscribe
>>>>> csound"
>>>>
>>>>
>>>>
>>>> --
>>>> ciao,
>>>> jAdams
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>>> "unsubscribe csound"
>>
>>
>>
>> --
>>
>>
>> Andrés
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>> "unsubscribe csound"
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"
>



Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Hi Michael,

The inlet/outlet/ftgenonce combination does work for encapsulated
instruments, but does not include graphical-user interfaces
per-instrument which blue does as well.  blue has had a system using
auto-generated global a- and k- signals as well as mechanisms for
generate ftables only once for quite some time now and technically
they are equivalent to the opcodes you mention.  (I may update blue's
generation style to use inlet/oulet and after experimenting with
ftgenonce may recommend that as a best practice for blue.)

There are also blue instruments like blueX7 in which the saved data is
just configuration; when the instrument is generated to CSD, it
creates the Csound code at that time.  The information in blueShare
would not be enough alone for another program to use unless they
implemented the same instrument generation code.

Also for a while now I have wanted to add the capability to have
always-on code for instruments. This is a common thing in MIDI-based
instruments--whether hardware or software--that for an instrument
there is audio code per-note and audio-code per-instrument.  Examples
of per-instrument being things like filters, effects, and reverb to
emulate a resonant body. This is possible now in blue to add
per-instrument effects by added effects to the mixer.  It works but is
not ideal in that it does not match exactly the model of instrument
building that I see elsewhere in real instrument situations and in
electronic music setups that I would like to see in blue.  When I have
a chance to build this into blue, I think it will be yet another thing
that other environments may have to implement if they want to be able
to reuse blue instruments from blueShare.

steven


On Sat, Jan 16, 2010 at 1:03 PM,   wrote:
> Right now, with the ftgenonce opcode and the signal flow graph opcodes,
> instruments based on the following template can be freely shared with
> collisions or mismatches IF they also agree on the meanings of the pfields,
> or of a common set of initial pfields (illustrated below):
>
> instr MyInstr
> insno = p1
> ionset = p2
> iduration = p3
> imidikey = p4
> imidivelocity = p5
> itable1 ftgenonce ....
> ...
> itableN ftgenonce
>
> ; instrument processing code here...
>
> outlet "ch1", aout1
> outlet "ch2", aout2
> ...
> outlet "chN", aoutN
> endin
>
> Connections from such instruments to outputs or effects are declared in the
> orchestra header. See the signal flow graph example in the Csound manual for
> a more complete explanation.
>
> Regards,
> Mike
> ----- Original Message ----- From: "Steven Yi" 
> To: 
> Sent: Saturday, January 16, 2010 12:32 PM
> Subject: [Csnd] Re: Re: Re: Re: [announce] blue 2.0.0
>
>
> Hi Andres,
>
> Just catching up on older emails now.  blueShare itself is open in
> that anyone can talk to the API (it uses xml-rpc, though I guess I
> should considering moving to JSON sometime).  However, the big issue
> is that what is stored in blueShare is just the XML-serialized version
> of the different instrument classes and the effects objects.  These
> then map to objects which other applications would need to have some
> concept for and support.  I think the best way to think of what is in
> blueShare and in blue is thinking of VST instruments and effects. Like
> VST, blue instruments and effects are--when coded
> correctly--completely self-contained and can be inserted into any
> project and automatically link into the audio-signal flow graph
> through the mixer.
>
> The issue with trying to reuse the data in blueShare in say,
> QuteCsound, is that I see diferences in the model for how interfaces
> are used.  An application like QuteCsound, MacCsound, or using FLTK
> widgets has a view where it's like you're building with Csound a
> standalone audio application. The single main interface then is
> reference-able by multiple csound instruments and there is no
> encapsulation into reusable parts.  Not to say one method is better
> than the other, just that the purposes are different, and there's sort
> of a cognitive dissonance in how to share information.
>
> As another example, blue also communicates to the Csound UDO
> repository over xml-rpc and is able to download UDO's directly from
> the website into the project.  This is possible because blue has a UDO
> object that it can wrap the incoming UDO with and then handle as a
> separate object.  In terms of other programs, unless they have this
> abstraction, the best they can do is download the UDO and directly
> insert the text into a CSD.
>
> If there is a desire to create a share-able respository for Csound
> programs, I think we'd have to come to some agreement on what we are
> sharing.  Would it be an instrument? An ftable definition?  (Could be
> useful if it could contain an attachment, so that we could store
> things like strike data for physical models...).  If we come up with
> the concepts of what to share, then we could look at creating a
> CsoundShare site.
>
> steven
>
>
> On Sat, Jan 9, 2010 at 5:33 AM, Andres Cabrera 
> wrote:
>>
>> Hi Steven,
>>
>> Nice work. Looks very polished.
>>
>> I've always thought that blue share could be a platform for
>> collaboration even across frontends. What do you think of the widget
>> format proposal I showed some time ago? Do you think it's worth trying
>> to implement it to encourage collaboration in blue share?
>>
>> Cheers,
>> Andrés
>>
>> On Fri, Jan 8, 2010 at 7:29 PM, Steven Yi  wrote:
>>>
>>> Thanks Jason and everyone!
>>>
>>> I'm hoping to also "reboot" blueShare by making a full website that
>>> will be both the home of blue (blue's new website) as well as
>>> blueShare as part of it. Hopefully can make it more community
>>> oriented, so things like seeing popularity of instruments/effects,
>>> comments, etc. I'm working on a design document now for MIDI and
>>> probably will try be a little more formal with how releases and things
>>> get put together. Part of the future of blueShare I think will go
>>> hand-in-hand with moving libraries from categories-based to tags-based
>>> (or perhaps keeping categories and adding tags).
>>>
>>> There's a lot on my mind now but it's going to take some time to get
>>> it all going. Hopefully we all benefit from it!
>>>
>>> Thanks!
>>> steven
>>>
>>> On Fri, Jan 8, 2010 at 1:46 PM, Jason a 
>>> wrote:
>>>>
>>>> AWESOME! just downloaded, gave it a good run-through and i'm impressed!
>>>> i
>>>> installed it and whammo, it worked... no fiddling, no noodling with
>>>> preferences, nothing! it seems a lot more stable in it's normal,
>>>> everyday
>>>> functions too (button pushing, screen switching, etc). i can't wait to
>>>> start composing with it. great job. big up to you Steven, and all of
>>>> your
>>>> cohorts/minions/associates/assistants, great work.
>>>>
>>>> jAdams
>>>>
>>>> On Thu, Jan 7, 2010 at 10:36 PM, Steven Yi  wrote:
>>>>>
>>>>> Hi All,
>>>>>
>>>>> After a long hiatus for releases, I am happy to announce blue 2.0.0 is
>>>>> now available at:
>>>>>
>>>>> http://www.csounds.com/stevenyi/blue
>>>>>
>>>>> (Note: the above site is old and will be updated for 2.1.0. The
>>>>> download can also be retrieved from the sourceforge site at
>>>>> http://sf.net/projects/bluemusic).
>>>>>
>>>>> The big change is that blue 2.0.0 has been rewritten to use the
>>>>> Nebeans Rich-Client Platform. This has taken quite a bit of time but
>>>>> I think the app has gained a lot of nice features in using the RCP
>>>>> libraries, particularly a nicer window system that users can customize
>>>>> the locations of windows of the app (i.e. move score side-by-side to
>>>>> orchestra, detach orchestra into it's own window to pull to a separate
>>>>> screen, etc.). Also, there a number of nice UI things in RCP that I
>>>>> have started to take advantage of.
>>>>>
>>>>> This release is feature-equivalent to blue 0.125.0 and projects that
>>>>> working 0.125.0 should work open up and work fine in blue 2.0.0. I am
>>>>> going to be ramping up my time on developing blue and moving forward
>>>>> with now with new feature development. Initial aims are to improve the
>>>>> PatternObject and to work on MIDI input for 2.1.0, as well as going
>>>>> through and taking care of issues in the bug and feature request
>>>>> databases on SourceForge.
>>>>>
>>>>> Documentation was only partially updated for this release and most of
>>>>> the documentation is still from 0.125.0. In reviewing the
>>>>> documentation I have decided that a larger reorganization of the
>>>>> documentation is necessary and this work has been scheduled for 2.1.0.
>>>>> For any questions regarding 2.0.0, please either email the blue users
>>>>> mailing list (preferred) or email me directly and I'll be happy to
>>>>> answer questions.
>>>>>
>>>>> A note on installation: for this release and for the foreseeable
>>>>> future, the application is now simply bundled in a zip file. Unzip
>>>>> the file and go into the blue/bin folder and run either blue.exe or
>>>>> the blue shell script to launch the application.
>>>>>
>>>>> Thank you to all of the blue users on on the blue mailing list who
>>>>> have provided feedback during the 2.0.0 beta releases: you have helped
>>>>> tremendously in helping to find bugs and make this release possible!
>>>>>
>>>>> Thanks an enjoy!
>>>>> steven
>>>>>
>>>>> p.s. - Thank you to Brian Wong for contributing new pieces for the
>>>>> examples folder! I know I have contacted a number of people for other
>>>>> contributions and may have lost them in the time 2.0.0 was being
>>>>> developed, my apologies! If you have a piece you would like to
>>>>> contribute, please email me and I would love to add them to blue for
>>>>> all users to study and enjoy!
>>>>>
>>>>> [CHANGE LOG]
>>>>>
>>>>> >Notes for 2.0.0 <
>>>>> [released 2010.01.07]
>>>>>
>>>>> Steven
>>>>>
>>>>> Yi-----------------------------------------------------------------------
>>>>>
>>>>> blue
>>>>>
>>>>> [new] - Converted application to use Netbeans Rich Client Platform to
>>>>> take
>>>>> advantage of new Window Manager and many libraries
>>>>>
>>>>> [new] - Added PulseAudio as driver option for Realtime Render settings
>>>>> on
>>>>> Linux
>>>>>
>>>>> [new] - Added pieces by Brian Wong to examples\pieces\brianWong folder
>>>>>
>>>>> [fix] - bug 2864419 - fixed importing multiline i- and f-statements
>>>>> when
>>>>> importing CSD or ORC/SCO; added multiline i-statment in score
>>>>> parser
>>>>>
>>>>>
>>>>> Send bugs reports to this list.
>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>>>>> "unsubscribe
>>>>> csound"
>>>>
>>>>
>>>>
>>>> --
>>>> ciao,
>>>> jAdams
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>> csound"
>>
>>
>>
>> --
>>
>>
>> Andrés
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>


Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Yes, I forgot to mention the alwayson opcode.

Thanks for the information about blue internals and usage, I will keep
this in mind in developing new stuff. I am aware of  GUI needs but not
sure what to do about them.

Perhaps something to bind a krate inlet to a widget, or a global
variable to a krate outlet.

Ideally, the widget would declare a control outlet and any instruments
could connect control inlets to that outlet.

Best,
Mike

On Sat, Jan 16, 2010 at 6:50 PM, Steven Yi  wrote:
> Hi Michael,
>
> The inlet/outlet/ftgenonce combination does work for encapsulated
> instruments, but does not include graphical-user interfaces
> per-instrument which blue does as well.  blue has had a system using
> auto-generated global a- and k- signals as well as mechanisms for
> generate ftables only once for quite some time now and technically
> they are equivalent to the opcodes you mention.  (I may update blue's
> generation style to use inlet/oulet and after experimenting with
> ftgenonce may recommend that as a best practice for blue.)
>
> There are also blue instruments like blueX7 in which the saved data is
> just configuration; when the instrument is generated to CSD, it
> creates the Csound code at that time.  The information in blueShare
> would not be enough alone for another program to use unless they
> implemented the same instrument generation code.
>
> Also for a while now I have wanted to add the capability to have
> always-on code for instruments. This is a common thing in MIDI-based
> instruments--whether hardware or software--that for an instrument
> there is audio code per-note and audio-code per-instrument.  Examples
> of per-instrument being things like filters, effects, and reverb to
> emulate a resonant body. This is possible now in blue to add
> per-instrument effects by added effects to the mixer.  It works but is
> not ideal in that it does not match exactly the model of instrument
> building that I see elsewhere in real instrument situations and in
> electronic music setups that I would like to see in blue.  When I have
> a chance to build this into blue, I think it will be yet another thing
> that other environments may have to implement if they want to be able
> to reuse blue instruments from blueShare.
>
> steven
>
>
> On Sat, Jan 16, 2010 at 1:03 PM,   wrote:
>> Right now, with the ftgenonce opcode and the signal flow graph opcodes,
>> instruments based on the following template can be freely shared with
>> collisions or mismatches IF they also agree on the meanings of the pfields,
>> or of a common set of initial pfields (illustrated below):
>>
>> instr MyInstr
>> insno = p1
>> ionset = p2
>> iduration = p3
>> imidikey = p4
>> imidivelocity = p5
>> itable1 ftgenonce ....
>> ...
>> itableN ftgenonce
>>
>> ; instrument processing code here...
>>
>> outlet "ch1", aout1
>> outlet "ch2", aout2
>> ...
>> outlet "chN", aoutN
>> endin
>>
>> Connections from such instruments to outputs or effects are declared in the
>> orchestra header. See the signal flow graph example in the Csound manual for
>> a more complete explanation.
>>
>> Regards,
>> Mike
>> ----- Original Message ----- From: "Steven Yi" 
>> To: 
>> Sent: Saturday, January 16, 2010 12:32 PM
>> Subject: [Csnd] Re: Re: Re: Re: [announce] blue 2.0.0
>>
>>
>> Hi Andres,
>>
>> Just catching up on older emails now.  blueShare itself is open in
>> that anyone can talk to the API (it uses xml-rpc, though I guess I
>> should considering moving to JSON sometime).  However, the big issue
>> is that what is stored in blueShare is just the XML-serialized version
>> of the different instrument classes and the effects objects.  These
>> then map to objects which other applications would need to have some
>> concept for and support.  I think the best way to think of what is in
>> blueShare and in blue is thinking of VST instruments and effects. Like
>> VST, blue instruments and effects are--when coded
>> correctly--completely self-contained and can be inserted into any
>> project and automatically link into the audio-signal flow graph
>> through the mixer.
>>
>> The issue with trying to reuse the data in blueShare in say,
>> QuteCsound, is that I see diferences in the model for how interfaces
>> are used.  An application like QuteCsound, MacCsound, or using FLTK
>> widgets has a view where it's like you're building with Csound a
>> standalone audio application. The single main interface then is
>> reference-able by multiple csound instruments and there is no
>> encapsulation into reusable parts.  Not to say one method is better
>> than the other, just that the purposes are different, and there's sort
>> of a cognitive dissonance in how to share information.
>>
>> As another example, blue also communicates to the Csound UDO
>> repository over xml-rpc and is able to download UDO's directly from
>> the website into the project.  This is possible because blue has a UDO
>> object that it can wrap the incoming UDO with and then handle as a
>> separate object.  In terms of other programs, unless they have this
>> abstraction, the best they can do is download the UDO and directly
>> insert the text into a CSD.
>>
>> If there is a desire to create a share-able respository for Csound
>> programs, I think we'd have to come to some agreement on what we are
>> sharing.  Would it be an instrument? An ftable definition?  (Could be
>> useful if it could contain an attachment, so that we could store
>> things like strike data for physical models...).  If we come up with
>> the concepts of what to share, then we could look at creating a
>> CsoundShare site.
>>
>> steven
>>
>>
>> On Sat, Jan 9, 2010 at 5:33 AM, Andres Cabrera 
>> wrote:
>>>
>>> Hi Steven,
>>>
>>> Nice work. Looks very polished.
>>>
>>> I've always thought that blue share could be a platform for
>>> collaboration even across frontends. What do you think of the widget
>>> format proposal I showed some time ago? Do you think it's worth trying
>>> to implement it to encourage collaboration in blue share?
>>>
>>> Cheers,
>>> Andrés
>>>
>>> On Fri, Jan 8, 2010 at 7:29 PM, Steven Yi  wrote:
>>>>
>>>> Thanks Jason and everyone!
>>>>
>>>> I'm hoping to also "reboot" blueShare by making a full website that
>>>> will be both the home of blue (blue's new website) as well as
>>>> blueShare as part of it. Hopefully can make it more community
>>>> oriented, so things like seeing popularity of instruments/effects,
>>>> comments, etc. I'm working on a design document now for MIDI and
>>>> probably will try be a little more formal with how releases and things
>>>> get put together. Part of the future of blueShare I think will go
>>>> hand-in-hand with moving libraries from categories-based to tags-based
>>>> (or perhaps keeping categories and adding tags).
>>>>
>>>> There's a lot on my mind now but it's going to take some time to get
>>>> it all going. Hopefully we all benefit from it!
>>>>
>>>> Thanks!
>>>> steven
>>>>
>>>> On Fri, Jan 8, 2010 at 1:46 PM, Jason a 
>>>> wrote:
>>>>>
>>>>> AWESOME! just downloaded, gave it a good run-through and i'm impressed!
>>>>> i
>>>>> installed it and whammo, it worked... no fiddling, no noodling with
>>>>> preferences, nothing! it seems a lot more stable in it's normal,
>>>>> everyday
>>>>> functions too (button pushing, screen switching, etc). i can't wait to
>>>>> start composing with it. great job. big up to you Steven, and all of
>>>>> your
>>>>> cohorts/minions/associates/assistants, great work.
>>>>>
>>>>> jAdams
>>>>>
>>>>> On Thu, Jan 7, 2010 at 10:36 PM, Steven Yi  wrote:
>>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> After a long hiatus for releases, I am happy to announce blue 2.0.0 is
>>>>>> now available at:
>>>>>>
>>>>>> http://www.csounds.com/stevenyi/blue
>>>>>>
>>>>>> (Note: the above site is old and will be updated for 2.1.0. The
>>>>>> download can also be retrieved from the sourceforge site at
>>>>>> http://sf.net/projects/bluemusic).
>>>>>>
>>>>>> The big change is that blue 2.0.0 has been rewritten to use the
>>>>>> Nebeans Rich-Client Platform. This has taken quite a bit of time but
>>>>>> I think the app has gained a lot of nice features in using the RCP
>>>>>> libraries, particularly a nicer window system that users can customize
>>>>>> the locations of windows of the app (i.e. move score side-by-side to
>>>>>> orchestra, detach orchestra into it's own window to pull to a separate
>>>>>> screen, etc.). Also, there a number of nice UI things in RCP that I
>>>>>> have started to take advantage of.
>>>>>>
>>>>>> This release is feature-equivalent to blue 0.125.0 and projects that
>>>>>> working 0.125.0 should work open up and work fine in blue 2.0.0. I am
>>>>>> going to be ramping up my time on developing blue and moving forward
>>>>>> with now with new feature development. Initial aims are to improve the
>>>>>> PatternObject and to work on MIDI input for 2.1.0, as well as going
>>>>>> through and taking care of issues in the bug and feature request
>>>>>> databases on SourceForge.
>>>>>>
>>>>>> Documentation was only partially updated for this release and most of
>>>>>> the documentation is still from 0.125.0. In reviewing the
>>>>>> documentation I have decided that a larger reorganization of the
>>>>>> documentation is necessary and this work has been scheduled for 2.1.0.
>>>>>> For any questions regarding 2.0.0, please either email the blue users
>>>>>> mailing list (preferred) or email me directly and I'll be happy to
>>>>>> answer questions.
>>>>>>
>>>>>> A note on installation: for this release and for the foreseeable
>>>>>> future, the application is now simply bundled in a zip file. Unzip
>>>>>> the file and go into the blue/bin folder and run either blue.exe or
>>>>>> the blue shell script to launch the application.
>>>>>>
>>>>>> Thank you to all of the blue users on on the blue mailing list who
>>>>>> have provided feedback during the 2.0.0 beta releases: you have helped
>>>>>> tremendously in helping to find bugs and make this release possible!
>>>>>>
>>>>>> Thanks an enjoy!
>>>>>> steven
>>>>>>
>>>>>> p.s. - Thank you to Brian Wong for contributing new pieces for the
>>>>>> examples folder! I know I have contacted a number of people for other
>>>>>> contributions and may have lost them in the time 2.0.0 was being
>>>>>> developed, my apologies! If you have a piece you would like to
>>>>>> contribute, please email me and I would love to add them to blue for
>>>>>> all users to study and enjoy!
>>>>>>
>>>>>> [CHANGE LOG]
>>>>>>
>>>>>> >Notes for 2.0.0 <
>>>>>> [released 2010.01.07]
>>>>>>
>>>>>> Steven
>>>>>>
>>>>>> Yi-----------------------------------------------------------------------
>>>>>>
>>>>>> blue
>>>>>>
>>>>>> [new] - Converted application to use Netbeans Rich Client Platform to
>>>>>> take
>>>>>> advantage of new Window Manager and many libraries
>>>>>>
>>>>>> [new] - Added PulseAudio as driver option for Realtime Render settings
>>>>>> on
>>>>>> Linux
>>>>>>
>>>>>> [new] - Added pieces by Brian Wong to examples\pieces\brianWong folder
>>>>>>
>>>>>> [fix] - bug 2864419 - fixed importing multiline i- and f-statements
>>>>>> when
>>>>>> importing CSD or ORC/SCO; added multiline i-statment in score
>>>>>> parser
>>>>>>
>>>>>>
>>>>>> Send bugs reports to this list.
>>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>>>>>> "unsubscribe
>>>>>> csound"
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> ciao,
>>>>> jAdams
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> Send bugs reports to this list.
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>>> csound"
>>>
>>>
>>>
>>> --
>>>
>>>
>>> Andrés
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>> csound"
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"



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


Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"