From jsyn at music.columbia.edu Mon Feb 16 07:30:01 2009 From: jsyn at music.columbia.edu (jsyn@music.columbia.edu) Date: Mon Feb 16 07:30:12 2009 Subject: [jsyn] Fully Funded Ph.D. Scholarships in Media and Arts Technology Message-ID: <59651f120902160430h26077cddkeaa9bb00c7ade575@mail.gmail.com> *Apologies for multiple posting* Ph.D. PROGRAMME IN MEDIA AND ARTS TECHNOLOGY EPSRC Centre for Doctoral Training. 10 Fully Funded Scholarships for 2009 http://www.mat.qmul.ac.uk Queen Mary University of London (QMUL) is one of the UK's leading research universities and is located at the heart of Europe's largest concentration of creative industries. We are launching an innovative inter-disciplinary training programme in the science and technologies that are transforming the creative sector. Our mission is to produce post-graduates who combine world-class technical and creative skills and who have a unique vision of how digital technology transforms creative possibilities and social economies. PROGRAMME STRUCTURE: You will work under the supervision of internationally recognised experts in: ? Digital Music ? Digital Video ? Human Interaction ? Performance and Live Art ? Digital Media Law. You will also develop a working partnership with one of our strategic collaborators including: APT sound connections, BBC, The British Film Institute, BigDog Interactive, BT, Codex, ELBA, Goldsmiths Department of Computing, Illustrious, Kodak, last.fm, LATERAL, LCACE, London Development Agency, LShift, Meridian, Noldus, Philips Research Laboratories, proboscis, QinetiQ, radioscape, University of the Arts London, SONY Computer Enterainment, Solid State Logic, [space], THE TALENT BUSINESS and TATE[1]. This is a unique 4 year Ph.D. programme. In your first year you will take courses in advanced research methods, interaction design and digital media processing, production and recording techniques. You follow this with a bespoke advanced placement project with one of our creative sector partners. In the second year you will select your research topic and take further specialist modules ranging from Digital Audio Effects through Digital Rights Management to Contemporary Performance. RESOURCES: Our programme is part of a ?250 million strategic initiative, funded by EPSRC, and is exceptionally well resourced. You will have access to QMUL's state-of-the art research and performance facilities including the Augmented Human Interaction Laboratory, the Pinter Studio Theatre and the Listening Room as well as the extensive resources offered by our industrial and public sector partners. SCHOLARSHIPS: 10 Scholarships are available in 2009 that provide an annual tax-free stipend of ?14,940, cover annual tuition fees (?3,300), national and international conference attendance and a laptop equipped with specialist software. Please note that due to external funding restrictions only UK citizens, or EU students who have been ordinarily resident in the UK for the last 3 years, are eligible for a scholarships. HOW TO APPLY: We invite applications from outstanding individuals with any Arts, Engineering or Science background. You must be able to demonstrate academic achievement at the level of a 2.i first degree or higher and excellent critical and analytic skills. For applicants with a science or technology background we are looking for people who can also demonstrate significant creative abilities. For applicants with an arts/humanities background we are looking for people who can also demonstrate a working knowledge of programming or good mathematical abilities. Deadline for the first round of scholarships is 30th March 2009. Email: mat-enquiries@eecs.qmul.ac.uk for further details on how to apply. From jsyn at music.columbia.edu Mon Feb 16 16:32:52 2009 From: jsyn at music.columbia.edu (jsyn@music.columbia.edu) Date: Mon Feb 16 16:33:01 2009 Subject: [jsyn] JSyn in pure Java Message-ID: <4999DB84.20601@softsynth.com> Yesterday I started rewriting the native part of JSyn in pure Java. As you know, the JSyn synthesis engine was written in native 'C' code. This was necessary in 1997 to get high fidelity audio and reasonable performance. In 2009 it is no longer necessary. Progress on JSyn has been slow these past few years, mostly because I spend most of my JSyn time on problems related to the native code plugin in browsers. Goals 1) Allow existing Applets to run without modification. 2) Allow old and new Applets to run in a browser without requiring a plugin. 3) Allow users to easily add their own unit generators. 4) Simplify development. 5) Support native audio interface if JavaSound not working well enough. How it Works I have created a new synthesis engine in a "com.jsyn" package. It will have an updated API using modern Java techniques and support plugins. I then modified SynthContext so that it calls the pure Java synthesizer through a bridge. This bridge code handles all the token and other weirdness that was necessary to support the native library. The old native synthesizer can still be called by using SynthContextNative. The old API in com.softsynth.jsyn will be frozen and new development made in the com.jsyn package. Developers can use either API but will be encouraged to move to the new API. Thoughts? Questions? Good idea? Bad idea? I will follow this with a letter describing some API changes. Thank you, Phil Burk --------------------------------------- SoftSynth, Audio Research and Development http://www.softsynth.com/ 75 Pleasant Lane, San Rafael, CA, 94901 USA Office: +1-415-453-4320 Mobile: +1-415-846-4370 FAX: +1-415-373-4428 --------------------------------------- From jsyn at music.columbia.edu Mon Feb 16 16:38:58 2009 From: jsyn at music.columbia.edu (jsyn@music.columbia.edu) Date: Mon Feb 16 16:39:01 2009 Subject: [jsyn] JSyn in pure Java In-Reply-To: <4999DB84.20601@softsynth.com> References: <4999DB84.20601@softsynth.com> Message-ID: <4999DCF2.8010507@music.columbia.edu> GREAT!!!!!!! jsyn@music.columbia.edu wrote: > Yesterday I started rewriting the native part of JSyn in pure Java. > > As you know, the JSyn synthesis engine was written in native 'C' code. > This was necessary in 1997 to get high fidelity audio and reasonable > performance. In 2009 it is no longer necessary. Progress on JSyn has > been slow these past few years, mostly because I spend most of my JSyn > time on problems related to the native code plugin in browsers. > > Goals > > 1) Allow existing Applets to run without modification. > > 2) Allow old and new Applets to run in a browser without requiring a > plugin. > > 3) Allow users to easily add their own unit generators. > > 4) Simplify development. > > 5) Support native audio interface if JavaSound not working well enough. > > > How it Works > > I have created a new synthesis engine in a "com.jsyn" package. It will > have an updated API using modern Java techniques and support plugins. > > I then modified SynthContext so that it calls the pure Java synthesizer > through a bridge. This bridge code handles all the token and other > weirdness that was necessary to support the native library. The old > native synthesizer can still be called by using SynthContextNative. > > The old API in com.softsynth.jsyn will be frozen and new development > made in the com.jsyn package. Developers can use either API but will be > encouraged to move to the new API. > > Thoughts? Questions? Good idea? Bad idea? > > I will follow this with a letter describing some API changes. > > Thank you, > Phil Burk > --------------------------------------- > SoftSynth, Audio Research and Development > http://www.softsynth.com/ > 75 Pleasant Lane, San Rafael, CA, 94901 USA > Office: +1-415-453-4320 > Mobile: +1-415-846-4370 > FAX: +1-415-373-4428 > --------------------------------------- > _______________________________________________ > JSyn mailing list > JSyn@music.columbia.edu > To change digest mode or to make other administrative changes visit: > http://music.columbia.edu/mailman/listinfo/jsyn > -- ............................................... http://artbots.org .....douglas.....irving........................ http://dorkbot.org .......................... http://music.columbia.edu/cmc/music-dsp .......... repetto............. http://music.columbia.edu/organism ............................... http://music.columbia.edu/~douglas From jsyn at music.columbia.edu Mon Feb 16 16:40:54 2009 From: jsyn at music.columbia.edu (jsyn@music.columbia.edu) Date: Mon Feb 16 16:41:08 2009 Subject: [jsyn] JSyn in pure Java In-Reply-To: <4999DB84.20601@softsynth.com> References: <4999DB84.20601@softsynth.com> Message-ID: This is _very_ interesting to me. I don't currently use jsyn, but this would be a strong enticement. What's the performance hit with java vs native code going to be? -Morgan On Mon, Feb 16, 2009 at 4:32 PM, wrote: > Yesterday I started rewriting the native part of JSyn in pure Java. > > As you know, the JSyn synthesis engine was written in native 'C' code. This > was necessary in 1997 to get high fidelity audio and reasonable performance. > In 2009 it is no longer necessary. Progress on JSyn has been slow these past > few years, mostly because I spend most of my JSyn time on problems related > to the native code plugin in browsers. > > Goals > > 1) Allow existing Applets to run without modification. > > 2) Allow old and new Applets to run in a browser without requiring a > plugin. > > 3) Allow users to easily add their own unit generators. > > 4) Simplify development. > > 5) Support native audio interface if JavaSound not working well enough. > > > How it Works > > I have created a new synthesis engine in a "com.jsyn" package. It will have > an updated API using modern Java techniques and support plugins. > > I then modified SynthContext so that it calls the pure Java synthesizer > through a bridge. This bridge code handles all the token and other weirdness > that was necessary to support the native library. The old native synthesizer > can still be called by using SynthContextNative. > > The old API in com.softsynth.jsyn will be frozen and new development made > in the com.jsyn package. Developers can use either API but will be > encouraged to move to the new API. > > Thoughts? Questions? Good idea? Bad idea? > > I will follow this with a letter describing some API changes. > > Thank you, > Phil Burk > --------------------------------------- > SoftSynth, Audio Research and Development > http://www.softsynth.com/ > 75 Pleasant Lane, San Rafael, CA, 94901 USA > Office: +1-415-453-4320 > Mobile: +1-415-846-4370 > FAX: +1-415-373-4428 > --------------------------------------- > _______________________________________________ > JSyn mailing list > JSyn@music.columbia.edu > To change digest mode or to make other administrative changes visit: > http://music.columbia.edu/mailman/listinfo/jsyn > -- +++++++++++++++++++++++++++++++++++++++ live at #3b -- listen! http://www.soundscaping.net/mixes/216/exclusive-mix-from-morgan-packard morganpackard.com myspace.com/morganpackard finediving.org anticipaterecordings.com (646) 206-8337 From jsyn at music.columbia.edu Mon Feb 16 16:49:54 2009 From: jsyn at music.columbia.edu (jsyn@music.columbia.edu) Date: Mon Feb 16 16:50:03 2009 Subject: [jsyn] JSyn in pure Java Message-ID: <21659055.1234820995284.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net> The question for my own work would be how this move to pure Java effects real-time thruput and overall audio processing latency given applications that are now using about all the avail cpu load modern personal computers. Though I know this is very important for some and a key selling point of java in general but browser based applets aren't my world - building applications meant to be run by themselves as performance instruments on stage is (and I love Java and Jsyn). I do love the idea of more access to the code / unit generators (including the possibility of of more interaction with back-end threading issues etc.) and in general back-end code that is easier to support for Phil and thus runs better (and develops quicker) for all of us. But for me, if my current level of real-time, often full-duplex, cpu intensity is going to lead to drop-outs, I'll be much bummed. thanks - C>T> -----Original Message----- >From: jsyn@music.columbia.edu >Sent: Feb 16, 2009 4:32 PM >To: jsyn discussion list >Subject: [jsyn] JSyn in pure Java > >Yesterday I started rewriting the native part of JSyn in pure Java. > >As you know, the JSyn synthesis engine was written in native 'C' code. >This was necessary in 1997 to get high fidelity audio and reasonable >performance. In 2009 it is no longer necessary. Progress on JSyn has >been slow these past few years, mostly because I spend most of my JSyn >time on problems related to the native code plugin in browsers. > >Goals > >1) Allow existing Applets to run without modification. > >2) Allow old and new Applets to run in a browser without requiring a plugin. > >3) Allow users to easily add their own unit generators. > >4) Simplify development. > >5) Support native audio interface if JavaSound not working well enough. > > >How it Works > >I have created a new synthesis engine in a "com.jsyn" package. It will >have an updated API using modern Java techniques and support plugins. > >I then modified SynthContext so that it calls the pure Java synthesizer >through a bridge. This bridge code handles all the token and other >weirdness that was necessary to support the native library. The old >native synthesizer can still be called by using SynthContextNative. > >The old API in com.softsynth.jsyn will be frozen and new development >made in the com.jsyn package. Developers can use either API but will be >encouraged to move to the new API. > >Thoughts? Questions? Good idea? Bad idea? > >I will follow this with a letter describing some API changes. > >Thank you, >Phil Burk >--------------------------------------- >SoftSynth, Audio Research and Development >http://www.softsynth.com/ >75 Pleasant Lane, San Rafael, CA, 94901 USA >Office: +1-415-453-4320 >Mobile: +1-415-846-4370 >FAX: +1-415-373-4428 >--------------------------------------- >_______________________________________________ >JSyn mailing list >JSyn@music.columbia.edu >To change digest mode or to make other administrative changes visit: >http://music.columbia.edu/mailman/listinfo/jsyn From jsyn at music.columbia.edu Mon Feb 16 16:57:52 2009 From: jsyn at music.columbia.edu (jsyn@music.columbia.edu) Date: Mon Feb 16 16:58:01 2009 Subject: [jsyn] JSyn in pure Java In-Reply-To: <4999DB84.20601@softsynth.com> References: <4999DB84.20601@softsynth.com> Message-ID: <4999E160.2030905@softsynth.com> Here are some API changes I am thinking of making in the new com.jsyn API. The old API will still be supported in com.softsynth.jsyn. Parts is Parts ------ Current JSyn ports can have multiple indexed parts. Thus when you connect an osc to a LineOut you write: osc.output.connect( 0, lineOut.input, 0 ); // left osc.output.connect( 0, lineOut.input, 1 ); // right These indexed parts are confusing and sometimes makes it hard to use ports. I propose that all new ports have only one part. So the code above in the new JSyn would be: osc.output.connect( lineOut.input0 ); // left osc.output.connect( lineOut.input1 ); // left Affected units will include LineIn, LineOut, PanUnit, CrossFade and others. The DualInTwoOut and TwoInDualOut units will no longer be needed. Miscellaneous Changes - Sleep related methods will throw InterruptedException like they are supposed to. - Do you want to allow multiple connections to an input? The incoming signals would automatically be added together. There may be a significant performance hit. Currently you have to use an AddUnit. Miscellaneous New Features - connect() will allow a timestamp - Samples can contain floating point data. Thank you, Phil Burk --------------------------------------- SoftSynth, Audio Research and Development http://www.softsynth.com/ 75 Pleasant Lane, San Rafael, CA, 94901 USA Office: +1-415-453-4320 Mobile: +1-415-846-4370 FAX: +1-415-373-4428 --------------------------------------- From jsyn at music.columbia.edu Mon Feb 16 17:46:06 2009 From: jsyn at music.columbia.edu (jsyn@music.columbia.edu) Date: Mon Feb 16 17:46:34 2009 Subject: [jsyn] JSyn in pure Java In-Reply-To: <4999DB84.20601@softsynth.com> Message-ID: Awesome. Let me know if I can help. Best, Mike On 2/16/09 1:32 PM, "jsyn@music.columbia.edu" wrote: > Yesterday I started rewriting the native part of JSyn in pure Java. > > As you know, the JSyn synthesis engine was written in native 'C' code. > This was necessary in 1997 to get high fidelity audio and reasonable > performance. In 2009 it is no longer necessary. Progress on JSyn has > been slow these past few years, mostly because I spend most of my JSyn > time on problems related to the native code plugin in browsers. > > Goals > > 1) Allow existing Applets to run without modification. > > 2) Allow old and new Applets to run in a browser without requiring a plugin. > > 3) Allow users to easily add their own unit generators. > > 4) Simplify development. > > 5) Support native audio interface if JavaSound not working well enough. > > > How it Works > > I have created a new synthesis engine in a "com.jsyn" package. It will > have an updated API using modern Java techniques and support plugins. > > I then modified SynthContext so that it calls the pure Java synthesizer > through a bridge. This bridge code handles all the token and other > weirdness that was necessary to support the native library. The old > native synthesizer can still be called by using SynthContextNative. > > The old API in com.softsynth.jsyn will be frozen and new development > made in the com.jsyn package. Developers can use either API but will be > encouraged to move to the new API. > > Thoughts? Questions? Good idea? Bad idea? > > I will follow this with a letter describing some API changes. > > Thank you, > Phil Burk > --------------------------------------- > SoftSynth, Audio Research and Development > http://www.softsynth.com/ > 75 Pleasant Lane, San Rafael, CA, 94901 USA > Office: +1-415-453-4320 > Mobile: +1-415-846-4370 > FAX: +1-415-373-4428 > --------------------------------------- > _______________________________________________ > JSyn mailing list > JSyn@music.columbia.edu > To change digest mode or to make other administrative changes visit: > http://music.columbia.edu/mailman/listinfo/jsyn From jsyn at music.columbia.edu Mon Feb 16 18:06:15 2009 From: jsyn at music.columbia.edu (jsyn@music.columbia.edu) Date: Mon Feb 16 18:06:40 2009 Subject: [jsyn] JSyn in pure Java Message-ID: <10488175.1234825576781.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net> great changes. happy to see parts go away. the more things with timestamp the better for sure. Multiple connections to an input would be very useful (for me) given the well-advertised caveat that this would incur a performance hit. I am presuming however that the performance hit would be equivalent to the old AddUnit method. right? thanks, C>T> -----Original Message----- >From: jsyn@music.columbia.edu >Sent: Feb 16, 2009 4:57 PM >To: "jsyn@music.columbia.edu" >Subject: Re: [jsyn] JSyn in pure Java > >Here are some API changes I am thinking of making in the new com.jsyn >API. The old API will still be supported in com.softsynth.jsyn. > >Parts is Parts ------ > >Current JSyn ports can have multiple indexed parts. Thus when you >connect an osc to a LineOut you write: > > osc.output.connect( 0, lineOut.input, 0 ); // left > osc.output.connect( 0, lineOut.input, 1 ); // right > >These indexed parts are confusing and sometimes makes it hard to use >ports. I propose that all new ports have only one part. So the code >above in the new JSyn would be: > > osc.output.connect( lineOut.input0 ); // left > osc.output.connect( lineOut.input1 ); // left > >Affected units will include LineIn, LineOut, PanUnit, CrossFade and >others. The DualInTwoOut and TwoInDualOut units will no longer be needed. > >Miscellaneous Changes > >- Sleep related methods will throw InterruptedException like they are >supposed to. > >- Do you want to allow multiple connections to an input? The incoming >signals would automatically be added together. There may be a >significant performance hit. Currently you have to use an AddUnit. > >Miscellaneous New Features > >- connect() will allow a timestamp > >- Samples can contain floating point data. > >Thank you, >Phil Burk >--------------------------------------- >SoftSynth, Audio Research and Development >http://www.softsynth.com/ >75 Pleasant Lane, San Rafael, CA, 94901 USA >Office: +1-415-453-4320 >Mobile: +1-415-846-4370 >FAX: +1-415-373-4428 >--------------------------------------- >_______________________________________________ >JSyn mailing list >JSyn@music.columbia.edu >To change digest mode or to make other administrative changes visit: >http://music.columbia.edu/mailman/listinfo/jsyn From jsyn at music.columbia.edu Mon Feb 16 18:22:42 2009 From: jsyn at music.columbia.edu (jsyn@music.columbia.edu) Date: Mon Feb 16 18:22:51 2009 Subject: [jsyn] JSyn in pure Java In-Reply-To: <10488175.1234825576781.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net> References: <10488175.1234825576781.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net> Message-ID: <4999F542.3070503@softsynth.com> > I am presuming however that the performance hit would be > equivalent to the old AddUnit method. right? For situations where you have multiple signals combined, yes. My concern is that there will be a hit even when you only have one connection because the code is more complex. Phil jsyn@music.columbia.edu wrote: > great changes. happy to see parts go away. > the more things with timestamp the better for sure. > > Multiple connections to an input would be very useful (for me) given the well-advertised caveat that this would incur a performance hit. I am presuming however that the performance hit would be equivalent to the old AddUnit method. right? > > thanks, > > C>T> > > -----Original Message----- >> From: jsyn@music.columbia.edu >> Sent: Feb 16, 2009 4:57 PM >> To: "jsyn@music.columbia.edu" >> Subject: Re: [jsyn] JSyn in pure Java >> >> - Do you want to allow multiple connections to an input? The incoming >> signals would automatically be added together. There may be a >> significant performance hit. Currently you have to use an AddUnit. From jsyn at music.columbia.edu Mon Feb 16 18:23:13 2009 From: jsyn at music.columbia.edu (jsyn@music.columbia.edu) Date: Mon Feb 16 18:23:24 2009 Subject: [jsyn] JSyn in pure Java In-Reply-To: <4999DB84.20601@softsynth.com> References: <4999DB84.20601@softsynth.com> Message-ID: <4999F561.5030202@woh.rr.com> jsyn@music.columbia.edu wrote: > Yesterday I started rewriting the native part of JSyn in pure Java. > Will this affect the likelihood of a Linux plugin ? Best, dp From jsyn at music.columbia.edu Mon Feb 16 18:25:01 2009 From: jsyn at music.columbia.edu (jsyn@music.columbia.edu) Date: Mon Feb 16 18:25:10 2009 Subject: [jsyn] JSyn in pure Java Message-ID: <26936713.1234826701950.JavaMail.root@elwamui-polski.atl.sa.earthlink.net> in that case I'd be more up for leaving it alone or adding a second connect method which implements the merge and performance hit if possible - C>T> -----Original Message----- >From: jsyn@music.columbia.edu >Sent: Feb 16, 2009 6:22 PM >To: "jsyn@music.columbia.edu" >Subject: Re: [jsyn] JSyn in pure Java > > > I am presuming however that the performance hit would be > > equivalent to the old AddUnit method. right? > >For situations where you have multiple signals combined, yes. > >My concern is that there will be a hit even when you only have one >connection because the code is more complex. > >Phil > > >jsyn@music.columbia.edu wrote: >> great changes. happy to see parts go away. >> the more things with timestamp the better for sure. >> >> Multiple connections to an input would be very useful (for me) given the well-advertised caveat that this would incur a performance hit. I am presuming however that the performance hit would be equivalent to the old AddUnit method. right? >> >> thanks, >> >> C>T> >> >> -----Original Message----- >>> From: jsyn@music.columbia.edu >>> Sent: Feb 16, 2009 4:57 PM >>> To: "jsyn@music.columbia.edu" >>> Subject: Re: [jsyn] JSyn in pure Java >>> >>> - Do you want to allow multiple connections to an input? The incoming >>> signals would automatically be added together. There may be a >>> significant performance hit. Currently you have to use an AddUnit. >_______________________________________________ >JSyn mailing list >JSyn@music.columbia.edu >To change digest mode or to make other administrative changes visit: >http://music.columbia.edu/mailman/listinfo/jsyn From jsyn at music.columbia.edu Mon Feb 16 18:34:20 2009 From: jsyn at music.columbia.edu (jsyn@music.columbia.edu) Date: Mon Feb 16 18:34:31 2009 Subject: [jsyn] JSyn in pure Java In-Reply-To: <4999DB84.20601@softsynth.com> References: <4999DB84.20601@softsynth.com> Message-ID: <10952851-88A5-475A-85FE-5495A257D02A@jasonfreeman.net> Hey Phil, This new version would make me seriously consider using JSyn again -- I've avoided it in recent years largely because of the requirement that users download the native code and the fact that I can't write my own unit generators. It sounds like this update would address both of those. Go Java go!! --Jason On Feb 16, 2009, at 4:32 PM, jsyn@music.columbia.edu wrote: > Yesterday I started rewriting the native part of JSyn in pure Java. > > As you know, the JSyn synthesis engine was written in native 'C' > code. This was necessary in 1997 to get high fidelity audio and > reasonable performance. In 2009 it is no longer necessary. Progress > on JSyn has been slow these past few years, mostly because I spend > most of my JSyn time on problems related to the native code plugin > in browsers. > > Goals > > 1) Allow existing Applets to run without modification. > > 2) Allow old and new Applets to run in a browser without requiring a > plugin. > > 3) Allow users to easily add their own unit generators. > > 4) Simplify development. > > 5) Support native audio interface if JavaSound not working well > enough. > > > How it Works > > I have created a new synthesis engine in a "com.jsyn" package. It > will have an updated API using modern Java techniques and support > plugins. > > I then modified SynthContext so that it calls the pure Java > synthesizer through a bridge. This bridge code handles all the token > and other weirdness that was necessary to support the native > library. The old native synthesizer can still be called by using > SynthContextNative. > > The old API in com.softsynth.jsyn will be frozen and new development > made in the com.jsyn package. Developers can use either API but will > be encouraged to move to the new API. > > Thoughts? Questions? Good idea? Bad idea? > > I will follow this with a letter describing some API changes. > > Thank you, > Phil Burk > --------------------------------------- > SoftSynth, Audio Research and Development > http://www.softsynth.com/ > 75 Pleasant Lane, San Rafael, CA, 94901 USA > Office: +1-415-453-4320 > Mobile: +1-415-846-4370 > FAX: +1-415-373-4428 > --------------------------------------- > _______________________________________________ > JSyn mailing list > JSyn@music.columbia.edu > To change digest mode or to make other administrative changes visit: > http://music.columbia.edu/mailman/listinfo/jsyn From jsyn at music.columbia.edu Mon Feb 16 18:39:00 2009 From: jsyn at music.columbia.edu (jsyn@music.columbia.edu) Date: Mon Feb 16 18:39:09 2009 Subject: [jsyn] JSyn in pure Java In-Reply-To: <4999F561.5030202@woh.rr.com> References: <4999DB84.20601@softsynth.com> <4999F561.5030202@woh.rr.com> Message-ID: <4999F914.1070908@softsynth.com> You will no longer need a plugin for Linux. JSyn will be pure Java and will run on Linux, SGI, Amiga, Windows, Mac OS or any other platform that supports Java and has a fast CPU. Thank you, Phil Burk --------------------------------------- SoftSynth, Audio Research and Development http://www.softsynth.com/ 75 Pleasant Lane, San Rafael, CA, 94901 USA Office: +1-415-453-4320 Mobile: +1-415-846-4370 FAX: +1-415-373-4428 --------------------------------------- jsyn@music.columbia.edu wrote: > jsyn@music.columbia.edu wrote: >> Yesterday I started rewriting the native part of JSyn in pure Java. >> > > Will this affect the likelihood of a Linux plugin ? > > Best, > > dp > > _______________________________________________ > JSyn mailing list > JSyn@music.columbia.edu > To change digest mode or to make other administrative changes visit: > http://music.columbia.edu/mailman/listinfo/jsyn > > From jsyn at music.columbia.edu Mon Feb 16 18:49:09 2009 From: jsyn at music.columbia.edu (jsyn@music.columbia.edu) Date: Mon Feb 16 18:49:39 2009 Subject: [jsyn] JSyn in pure Java In-Reply-To: <4999E160.2030905@softsynth.com> References: <4999DB84.20601@softsynth.com> <4999E160.2030905@softsynth.com> Message-ID: <4999FB75.2060108@mail.rockefeller.edu> Hi Phil I for one would be pretty unhappy to see indexed parts go away. Consider what happens in JMSL when you create a SynthNote Instrument: It examines the SynthNote and looks for an output port named, specifically, "output" . It then discovers how many parts does it have. The instrument stores that information and makes it accessible with public methods. This makes great things possible... for example, when you add that instrument to a JMSL Mixer, the mixer asks the instrument how many parts its output has, creates the requisite number of faders, and connects them. If we start naming outputs with names like "outputLeft", "outputRight", "outL", "outR", output0", "output1", "output2" we lose the power to query for a well-defined name. If we lose indexed parts, we lose the ability to nimbly enumerate through an output's parts and do higher level automatic stuff with them. Right now I cannot think of an example where the current model sometimes makes it hard to use ports. The only drawback I see is that the current implementation has always felt to me like it needed to be extended so that users can create their own N-Part output for their SynthNotes. So I was hoping for a N-Part unit that we could plug multiple outputs into, and have them all served as parts of the same output port. Something like: class MySynthNote extends SynthNote { ... add(my3PartOutput = new NPartOutput(3), "output"); ... myPanUnit.output.connect(0, my3PartOutput , 0); myPanUnit.output.connect(1, my3PartOutput , 1); myStateVariableFilter.highPass.connect(0, my3PartOutput , 2); ... // now we've got a SynthNote with a single "output" where part 0 is the L of the pan, part 1 is the R of the pan, and part 2 is the highPass output of the StateVariableFilter. Cool! With respect to confusion, an overridden version of connect() with two params that assumes part 0 for the output might be nice. osc.output.connect( lineOut.input, 0 ); // left osc.output.connect( lineOut.input, 1 ); // right ...instead of ... osc.output.connect( 0, lineOut.input, 0 ); // left osc.output.connect( 0, lineOut.input, 1 ); // right Thanks, Nick Didkovsky jsyn@music.columbia.edu wrote: > Here are some API changes I am thinking of making in the new com.jsyn > API. The old API will still be supported in com.softsynth.jsyn. > > Parts is Parts ------ > > Current JSyn ports can have multiple indexed parts. Thus when you > connect an osc to a LineOut you write: > > osc.output.connect( 0, lineOut.input, 0 ); // left > osc.output.connect( 0, lineOut.input, 1 ); // right > > These indexed parts are confusing and sometimes makes it hard to use > ports. I propose that all new ports have only one part. So the code > above in the new JSyn would be: > > osc.output.connect( lineOut.input0 ); // left > osc.output.connect( lineOut.input1 ); // left > > Affected units will include LineIn, LineOut, PanUnit, CrossFade and > others. The DualInTwoOut and TwoInDualOut units will no longer be needed. > > Miscellaneous Changes > > - Sleep related methods will throw InterruptedException like they are > supposed to. > > - Do you want to allow multiple connections to an input? The incoming > signals would automatically be added together. There may be a > significant performance hit. Currently you have to use an AddUnit. > > Miscellaneous New Features > > - connect() will allow a timestamp > > - Samples can contain floating point data. > > Thank you, > Phil Burk > --------------------------------------- > SoftSynth, Audio Research and Development > http://www.softsynth.com/ > 75 Pleasant Lane, San Rafael, CA, 94901 USA > Office: +1-415-453-4320 > Mobile: +1-415-846-4370 > FAX: +1-415-373-4428 > --------------------------------------- > _______________________________________________ > JSyn mailing list > JSyn@music.columbia.edu > To change digest mode or to make other administrative changes visit: > http://music.columbia.edu/mailman/listinfo/jsyn From jsyn at music.columbia.edu Mon Feb 16 18:54:53 2009 From: jsyn at music.columbia.edu (jsyn@music.columbia.edu) Date: Mon Feb 16 18:54:56 2009 Subject: [jsyn] JSyn in pure Java In-Reply-To: <4999FB75.2060108@mail.rockefeller.edu> References: <4999DB84.20601@softsynth.com> <4999E160.2030905@softsynth.com> <4999FB75.2060108@mail.rockefeller.edu> Message-ID: <4999FCCD.7080305@music.columbia.edu> My problem with indexed parts has always been with the documentation and nomenclature, not with the indexing itself. So if there were a cleaner way to present the interface while keeping the indexing behind the scenes, I think that'd be fine. It's a shame to have something nice and legible like: "myStateVariableFilter.highPass.connect" followed by: (0, lineout.input, 1) Huh? douglas jsyn@music.columbia.edu wrote: > Hi Phil > > I for one would be pretty unhappy to see indexed parts go away. > > Consider what happens in JMSL when you create a SynthNote Instrument: It > examines the SynthNote and looks for an output port named, specifically, > "output" . It then discovers how many parts does it have. The > instrument stores that information and makes it accessible with public > methods. This makes great things possible... for example, when you add > that instrument to a JMSL Mixer, the mixer asks the instrument how many > parts its output has, creates the requisite number of faders, and > connects them. > > If we start naming outputs with names like "outputLeft", "outputRight", > "outL", "outR", output0", "output1", "output2" we lose the power to > query for a well-defined name. If we lose indexed parts, we lose the > ability to nimbly enumerate through an output's parts and do higher > level automatic stuff with them. > > Right now I cannot think of an example where the current model sometimes > makes it hard to use ports. The only drawback I see is that the current > implementation has always felt to me like it needed to be extended so > that users can create their own N-Part output for their SynthNotes. So I > was hoping for a N-Part unit that we could plug multiple outputs into, > and have them all served as parts of the same output port. > > Something like: > class MySynthNote extends SynthNote { > ... > add(my3PartOutput = new NPartOutput(3), "output"); > ... > myPanUnit.output.connect(0, my3PartOutput , 0); > myPanUnit.output.connect(1, my3PartOutput , 1); > myStateVariableFilter.highPass.connect(0, my3PartOutput , 2); > ... > // now we've got a SynthNote with a single "output" where part 0 is the > L of the pan, part 1 is the R of the pan, and part 2 is the highPass > output of the StateVariableFilter. Cool! > > With respect to confusion, an overridden version of connect() with two > params that assumes part 0 for the output might be nice. > osc.output.connect( lineOut.input, 0 ); // left > osc.output.connect( lineOut.input, 1 ); // right > ...instead of ... > osc.output.connect( 0, lineOut.input, 0 ); // left > osc.output.connect( 0, lineOut.input, 1 ); // right > > Thanks, > Nick Didkovsky > > jsyn@music.columbia.edu wrote: >> Here are some API changes I am thinking of making in the new com.jsyn >> API. The old API will still be supported in com.softsynth.jsyn. >> >> Parts is Parts ------ >> >> Current JSyn ports can have multiple indexed parts. Thus when you >> connect an osc to a LineOut you write: >> >> osc.output.connect( 0, lineOut.input, 0 ); // left >> osc.output.connect( 0, lineOut.input, 1 ); // right >> >> These indexed parts are confusing and sometimes makes it hard to use >> ports. I propose that all new ports have only one part. So the code >> above in the new JSyn would be: >> >> osc.output.connect( lineOut.input0 ); // left >> osc.output.connect( lineOut.input1 ); // left >> >> Affected units will include LineIn, LineOut, PanUnit, CrossFade and >> others. The DualInTwoOut and TwoInDualOut units will no longer be needed. >> >> Miscellaneous Changes >> >> - Sleep related methods will throw InterruptedException like they are >> supposed to. >> >> - Do you want to allow multiple connections to an input? The incoming >> signals would automatically be added together. There may be a >> significant performance hit. Currently you have to use an AddUnit. >> >> Miscellaneous New Features >> >> - connect() will allow a timestamp >> >> - Samples can contain floating point data. >> >> Thank you, >> Phil Burk >> --------------------------------------- >> SoftSynth, Audio Research and Development >> http://www.softsynth.com/ >> 75 Pleasant Lane, San Rafael, CA, 94901 USA >> Office: +1-415-453-4320 >> Mobile: +1-415-846-4370 >> FAX: +1-415-373-4428 >> --------------------------------------- >> _______________________________________________ >> JSyn mailing list >> JSyn@music.columbia.edu >> To change digest mode or to make other administrative changes visit: >> http://music.columbia.edu/mailman/listinfo/jsyn > _______________________________________________ > JSyn mailing list > JSyn@music.columbia.edu > To change digest mode or to make other administrative changes visit: > http://music.columbia.edu/mailman/listinfo/jsyn > -- ............................................... http://artbots.org .....douglas.....irving........................ http://dorkbot.org .......................... http://music.columbia.edu/cmc/music-dsp .......... repetto............. http://music.columbia.edu/organism ............................... http://music.columbia.edu/~douglas From jsyn at music.columbia.edu Mon Feb 16 20:04:58 2009 From: jsyn at music.columbia.edu (jsyn@music.columbia.edu) Date: Mon Feb 16 20:05:07 2009 Subject: [jsyn] JSyn in pure Java Message-ID: <32200421.1234832698749.JavaMail.root@elwamui-rustique.atl.sa.earthlink.net> Maybe the issue then is just to have a method in a root class that allows user-defined naming and user-defined query of parts for specific objects at runtime so you can put your own business logic in there for accessing stuff. Those who use this more legible route just have to incur some Hastable equivalent lookup hit for each access. But behind the scenes after the name-mapping its still the same and can still be accessed as such for generic automated access as Nick suggests. Would this work? C>T> -----Original Message----- >From: jsyn@music.columbia.edu >Sent: Feb 16, 2009 6:54 PM >To: "jsyn@music.columbia.edu" >Subject: Re: [jsyn] JSyn in pure Java > > >My problem with indexed parts has always been with the documentation and >nomenclature, not with the indexing itself. So if there were a cleaner >way to present the interface while keeping the indexing behind the >scenes, I think that'd be fine. It's a shame to have something nice and >legible like: > >"myStateVariableFilter.highPass.connect" > >followed by: > >(0, lineout.input, 1) > > >Huh? > > >douglas > >jsyn@music.columbia.edu wrote: >> Hi Phil >> >> I for one would be pretty unhappy to see indexed parts go away. >> >> Consider what happens in JMSL when you create a SynthNote Instrument: It >> examines the SynthNote and looks for an output port named, specifically, >> "output" . It then discovers how many parts does it have. The >> instrument stores that information and makes it accessible with public >> methods. This makes great things possible... for example, when you add >> that instrument to a JMSL Mixer, the mixer asks the instrument how many >> parts its output has, creates the requisite number of faders, and >> connects them. >> >> If we start naming outputs with names like "outputLeft", "outputRight", >> "outL", "outR", output0", "output1", "output2" we lose the power to >> query for a well-defined name. If we lose indexed parts, we lose the >> ability to nimbly enumerate through an output's parts and do higher >> level automatic stuff with them. >> >> Right now I cannot think of an example where the current model sometimes >> makes it hard to use ports. The only drawback I see is that the current >> implementation has always felt to me like it needed to be extended so >> that users can create their own N-Part output for their SynthNotes. So I >> was hoping for a N-Part unit that we could plug multiple outputs into, >> and have them all served as parts of the same output port. >> >> Something like: >> class MySynthNote extends SynthNote { >> ... >> add(my3PartOutput = new NPartOutput(3), "output"); >> ... >> myPanUnit.output.connect(0, my3PartOutput , 0); >> myPanUnit.output.connect(1, my3PartOutput , 1); >> myStateVariableFilter.highPass.connect(0, my3PartOutput , 2); >> ... >> // now we've got a SynthNote with a single "output" where part 0 is the >> L of the pan, part 1 is the R of the pan, and part 2 is the highPass >> output of the StateVariableFilter. Cool! >> >> With respect to confusion, an overridden version of connect() with two >> params that assumes part 0 for the output might be nice. >> osc.output.connect( lineOut.input, 0 ); // left >> osc.output.connect( lineOut.input, 1 ); // right >> ...instead of ... >> osc.output.connect( 0, lineOut.input, 0 ); // left >> osc.output.connect( 0, lineOut.input, 1 ); // right >> >> Thanks, >> Nick Didkovsky >> >> jsyn@music.columbia.edu wrote: >>> Here are some API changes I am thinking of making in the new com.jsyn >>> API. The old API will still be supported in com.softsynth.jsyn. >>> >>> Parts is Parts ------ >>> >>> Current JSyn ports can have multiple indexed parts. Thus when you >>> connect an osc to a LineOut you write: >>> >>> osc.output.connect( 0, lineOut.input, 0 ); // left >>> osc.output.connect( 0, lineOut.input, 1 ); // right >>> >>> These indexed parts are confusing and sometimes makes it hard to use >>> ports. I propose that all new ports have only one part. So the code >>> above in the new JSyn would be: >>> >>> osc.output.connect( lineOut.input0 ); // left >>> osc.output.connect( lineOut.input1 ); // left >>> >>> Affected units will include LineIn, LineOut, PanUnit, CrossFade and >>> others. The DualInTwoOut and TwoInDualOut units will no longer be needed. >>> >>> Miscellaneous Changes >>> >>> - Sleep related methods will throw InterruptedException like they are >>> supposed to. >>> >>> - Do you want to allow multiple connections to an input? The incoming >>> signals would automatically be added together. There may be a >>> significant performance hit. Currently you have to use an AddUnit. >>> >>> Miscellaneous New Features >>> >>> - connect() will allow a timestamp >>> >>> - Samples can contain floating point data. >>> >>> Thank you, >>> Phil Burk >>> --------------------------------------- >>> SoftSynth, Audio Research and Development >>> http://www.softsynth.com/ >>> 75 Pleasant Lane, San Rafael, CA, 94901 USA >>> Office: +1-415-453-4320 >>> Mobile: +1-415-846-4370 >>> FAX: +1-415-373-4428 >>> --------------------------------------- >>> _______________________________________________ >>> JSyn mailing list >>> JSyn@music.columbia.edu >>> To change digest mode or to make other administrative changes visit: >>> http://music.columbia.edu/mailman/listinfo/jsyn >> _______________________________________________ >> JSyn mailing list >> JSyn@music.columbia.edu >> To change digest mode or to make other administrative changes visit: >> http://music.columbia.edu/mailman/listinfo/jsyn >> > >-- >............................................... http://artbots.org >.....douglas.....irving........................ http://dorkbot.org >.......................... http://music.columbia.edu/cmc/music-dsp >.......... repetto............. http://music.columbia.edu/organism >............................... http://music.columbia.edu/~douglas > >_______________________________________________ >JSyn mailing list >JSyn@music.columbia.edu >To change digest mode or to make other administrative changes visit: >http://music.columbia.edu/mailman/listinfo/jsyn From jsyn at music.columbia.edu Mon Feb 16 20:16:54 2009 From: jsyn at music.columbia.edu (jsyn@music.columbia.edu) Date: Mon Feb 16 20:17:04 2009 Subject: [jsyn] JSyn in pure Java In-Reply-To: <32200421.1234832698749.JavaMail.root@elwamui-rustique.atl.sa.earthlink.net> References: <32200421.1234832698749.JavaMail.root@elwamui-rustique.atl.sa.earthlink.net> Message-ID: <7e0db6c00902161716v1edeecex3fe947ffe107770d@mail.gmail.com> ...Does anybody know what happened to CSound and, what is the most stable GUI front end for CSound? On Mon, Feb 16, 2009 at 8:04 PM, wrote: > Maybe the issue then is just to have a method in a root class that allows > user-defined naming and user-defined query of parts for specific objects at > runtime so you can put your own business logic in there for accessing stuff. > Those who use this more legible route just have to incur some Hastable > equivalent lookup hit for each access. But behind the scenes after the > name-mapping its still the same and can still be accessed as such for > generic automated access as Nick suggests. Would this work? > > C>T> > > -----Original Message----- > >From: jsyn@music.columbia.edu > >Sent: Feb 16, 2009 6:54 PM > >To: "jsyn@music.columbia.edu" > >Subject: Re: [jsyn] JSyn in pure Java > > > > > >My problem with indexed parts has always been with the documentation and > >nomenclature, not with the indexing itself. So if there were a cleaner > >way to present the interface while keeping the indexing behind the > >scenes, I think that'd be fine. It's a shame to have something nice and > >legible like: > > > >"myStateVariableFilter.highPass.connect" > > > >followed by: > > > >(0, lineout.input, 1) > > > > > >Huh? > > > > > >douglas > > > >jsyn@music.columbia.edu wrote: > >> Hi Phil > >> > >> I for one would be pretty unhappy to see indexed parts go away. > >> > >> Consider what happens in JMSL when you create a SynthNote Instrument: It > >> examines the SynthNote and looks for an output port named, specifically, > >> "output" . It then discovers how many parts does it have. The > >> instrument stores that information and makes it accessible with public > >> methods. This makes great things possible... for example, when you add > >> that instrument to a JMSL Mixer, the mixer asks the instrument how many > >> parts its output has, creates the requisite number of faders, and > >> connects them. > >> > >> If we start naming outputs with names like "outputLeft", "outputRight", > >> "outL", "outR", output0", "output1", "output2" we lose the power to > >> query for a well-defined name. If we lose indexed parts, we lose the > >> ability to nimbly enumerate through an output's parts and do higher > >> level automatic stuff with them. > >> > >> Right now I cannot think of an example where the current model sometimes > >> makes it hard to use ports. The only drawback I see is that the current > >> implementation has always felt to me like it needed to be extended so > >> that users can create their own N-Part output for their SynthNotes. So I > >> was hoping for a N-Part unit that we could plug multiple outputs into, > >> and have them all served as parts of the same output port. > >> > >> Something like: > >> class MySynthNote extends SynthNote { > >> ... > >> add(my3PartOutput = new NPartOutput(3), "output"); > >> ... > >> myPanUnit.output.connect(0, my3PartOutput , 0); > >> myPanUnit.output.connect(1, my3PartOutput , 1); > >> myStateVariableFilter.highPass.connect(0, my3PartOutput , 2); > >> ... > >> // now we've got a SynthNote with a single "output" where part 0 is the > >> L of the pan, part 1 is the R of the pan, and part 2 is the highPass > >> output of the StateVariableFilter. Cool! > >> > >> With respect to confusion, an overridden version of connect() with two > >> params that assumes part 0 for the output might be nice. > >> osc.output.connect( lineOut.input, 0 ); // left > >> osc.output.connect( lineOut.input, 1 ); // right > >> ...instead of ... > >> osc.output.connect( 0, lineOut.input, 0 ); // left > >> osc.output.connect( 0, lineOut.input, 1 ); // right > >> > >> Thanks, > >> Nick Didkovsky > >> > >> jsyn@music.columbia.edu wrote: > >>> Here are some API changes I am thinking of making in the new com.jsyn > >>> API. The old API will still be supported in com.softsynth.jsyn. > >>> > >>> Parts is Parts ------ > >>> > >>> Current JSyn ports can have multiple indexed parts. Thus when you > >>> connect an osc to a LineOut you write: > >>> > >>> osc.output.connect( 0, lineOut.input, 0 ); // left > >>> osc.output.connect( 0, lineOut.input, 1 ); // right > >>> > >>> These indexed parts are confusing and sometimes makes it hard to use > >>> ports. I propose that all new ports have only one part. So the code > >>> above in the new JSyn would be: > >>> > >>> osc.output.connect( lineOut.input0 ); // left > >>> osc.output.connect( lineOut.input1 ); // left > >>> > >>> Affected units will include LineIn, LineOut, PanUnit, CrossFade and > >>> others. The DualInTwoOut and TwoInDualOut units will no longer be > needed. > >>> > >>> Miscellaneous Changes > >>> > >>> - Sleep related methods will throw InterruptedException like they are > >>> supposed to. > >>> > >>> - Do you want to allow multiple connections to an input? The incoming > >>> signals would automatically be added together. There may be a > >>> significant performance hit. Currently you have to use an AddUnit. > >>> > >>> Miscellaneous New Features > >>> > >>> - connect() will allow a timestamp > >>> > >>> - Samples can contain floating point data. > >>> > >>> Thank you, > >>> Phil Burk > >>> --------------------------------------- > >>> SoftSynth, Audio Research and Development > >>> http://www.softsynth.com/ > >>> 75 Pleasant Lane, San Rafael, CA, 94901 USA > >>> Office: +1-415-453-4320 > >>> Mobile: +1-415-846-4370 > >>> FAX: +1-415-373-4428 > >>> --------------------------------------- > >>> _______________________________________________ > >>> JSyn mailing list > >>> JSyn@music.columbia.edu > >>> To change digest mode or to make other administrative changes visit: > >>> http://music.columbia.edu/mailman/listinfo/jsyn > >> _______________________________________________ > >> JSyn mailing list > >> JSyn@music.columbia.edu > >> To change digest mode or to make other administrative changes visit: > >> http://music.columbia.edu/mailman/listinfo/jsyn > >> > > > >-- > >............................................... http://artbots.org > >.....douglas.....irving........................ http://dorkbot.org > >.......................... http://music.columbia.edu/cmc/music-dsp > >.......... repetto............. http://music.columbia.edu/organism > >............................... http://music.columbia.edu/~douglas > > > >_______________________________________________ > >JSyn mailing list > >JSyn@music.columbia.edu > >To change digest mode or to make other administrative changes visit: > >http://music.columbia.edu/mailman/listinfo/jsyn > > _______________________________________________ > JSyn mailing list > JSyn@music.columbia.edu > To change digest mode or to make other administrative changes visit: > http://music.columbia.edu/mailman/listinfo/jsyn > From jsyn at music.columbia.edu Mon Feb 16 20:21:55 2009 From: jsyn at music.columbia.edu (jsyn@music.columbia.edu) Date: Mon Feb 16 20:22:07 2009 Subject: [jsyn] JSyn in pure Java In-Reply-To: <4999FB75.2060108@mail.rockefeller.edu> References: <4999DB84.20601@softsynth.com> <4999E160.2030905@softsynth.com> <4999FB75.2060108@mail.rockefeller.edu> Message-ID: <499A1133.6010403@softsynth.com> Hi Nick, > I for one would be pretty unhappy to see indexed parts go away. Good reason to keep them. > Consider what happens in JMSL when you create a SynthNote Instrument: It > examines the SynthNote and looks for an output port named, specifically, > "output" . It then discovers how many parts does it have. You could probably still do something like this. You could either scan for "Input0,1,2". Or you could scan all the ports and see which ones were instanceof SynthOutput. > Right now I cannot think of an example where the current > model sometimes makes it hard to use ports. All the port handling code also has to deal with parts. So the pain is widely spread. Making ports in Circuits has always been a pain. Wire has to add its own numbers to show parts of a port. > osc.output.connect( lineOut.input, 0 ); // left > ...instead of ... > osc.output.connect( 0, lineOut.input, 0 ); // left Nice. I just added that. Also: lineIn.output.connect( 1, filter.input ); // right input > add(my3PartOutput = new NPartOutput(3), "output"); I'll have to think about that. Might be tricky. I guess it is similar to a SynthDistributor because it is a fake port that only exists at the top level. May be easier to do in JSyn2. Thank you, Phil Burk --------------------------------------- SoftSynth, Audio Research and Development http://www.softsynth.com/ 75 Pleasant Lane, San Rafael, CA, 94901 USA Office: +1-415-453-4320 Mobile: +1-415-846-4370 FAX: +1-415-373-4428 --------------------------------------- jsyn@music.columbia.edu wrote: > Hi Phil > > I for one would be pretty unhappy to see indexed parts go away. > > Consider what happens in JMSL when you create a SynthNote Instrument: It > examines the SynthNote and looks for an output port named, specifically, > "output" . It then discovers how many parts does it have. The > instrument stores that information and makes it accessible with public > methods. This makes great things possible... for example, when you add > that instrument to a JMSL Mixer, the mixer asks the instrument how many > parts its output has, creates the requisite number of faders, and > connects them. > > If we start naming outputs with names like "outputLeft", "outputRight", > "outL", "outR", output0", "output1", "output2" we lose the power to > query for a well-defined name. If we lose indexed parts, we lose the > ability to nimbly enumerate through an output's parts and do higher > level automatic stuff with them. > > Right now I cannot think of an example where the current model sometimes > makes it hard to use ports. The only drawback I see is that the current > implementation has always felt to me like it needed to be extended so > that users can create their own N-Part output for their SynthNotes. So I > was hoping for a N-Part unit that we could plug multiple outputs into, > and have them all served as parts of the same output port. > > Something like: > class MySynthNote extends SynthNote { > ... > add(my3PartOutput = new NPartOutput(3), "output"); > ... > myPanUnit.output.connect(0, my3PartOutput , 0); > myPanUnit.output.connect(1, my3PartOutput , 1); > myStateVariableFilter.highPass.connect(0, my3PartOutput , 2); > ... > // now we've got a SynthNote with a single "output" where part 0 is the > L of the pan, part 1 is the R of the pan, and part 2 is the highPass > output of the StateVariableFilter. Cool! > > With respect to confusion, an overridden version of connect() with two > params that assumes part 0 for the output might be nice. > osc.output.connect( lineOut.input, 0 ); // left > osc.output.connect( lineOut.input, 1 ); // right > ...instead of ... > osc.output.connect( 0, lineOut.input, 0 ); // left > osc.output.connect( 0, lineOut.input, 1 ); // right > > Thanks, > Nick Didkovsky > > jsyn@music.columbia.edu wrote: >> Here are some API changes I am thinking of making in the new com.jsyn >> API. The old API will still be supported in com.softsynth.jsyn. >> >> Parts is Parts ------ >> >> Current JSyn ports can have multiple indexed parts. Thus when you >> connect an osc to a LineOut you write: >> >> osc.output.connect( 0, lineOut.input, 0 ); // left >> osc.output.connect( 0, lineOut.input, 1 ); // right >> >> These indexed parts are confusing and sometimes makes it hard to use >> ports. I propose that all new ports have only one part. So the code >> above in the new JSyn would be: >> >> osc.output.connect( lineOut.input0 ); // left >> osc.output.connect( lineOut.input1 ); // left >> >> Affected units will include LineIn, LineOut, PanUnit, CrossFade and >> others. The DualInTwoOut and TwoInDualOut units will no longer be needed. >> >> Miscellaneous Changes >> >> - Sleep related methods will throw InterruptedException like they are >> supposed to. >> >> - Do you want to allow multiple connections to an input? The incoming >> signals would automatically be added together. There may be a >> significant performance hit. Currently you have to use an AddUnit. >> >> Miscellaneous New Features >> >> - connect() will allow a timestamp >> >> - Samples can contain floating point data. >> >> Thank you, >> Phil Burk >> --------------------------------------- >> SoftSynth, Audio Research and Development >> http://www.softsynth.com/ >> 75 Pleasant Lane, San Rafael, CA, 94901 USA >> Office: +1-415-453-4320 >> Mobile: +1-415-846-4370 >> FAX: +1-415-373-4428 >> --------------------------------------- >> _______________________________________________ >> JSyn mailing list >> JSyn@music.columbia.edu >> To change digest mode or to make other administrative changes visit: >> http://music.columbia.edu/mailman/listinfo/jsyn > _______________________________________________ > JSyn mailing list > JSyn@music.columbia.edu > To change digest mode or to make other administrative changes visit: > http://music.columbia.edu/mailman/listinfo/jsyn > > From jsyn at music.columbia.edu Mon Feb 16 20:30:07 2009 From: jsyn at music.columbia.edu (jsyn@music.columbia.edu) Date: Mon Feb 16 20:30:17 2009 Subject: [jsyn] latest CSound In-Reply-To: <7e0db6c00902161716v1edeecex3fe947ffe107770d@mail.gmail.com> References: <32200421.1234832698749.JavaMail.root@elwamui-rustique.atl.sa.earthlink.net> <7e0db6c00902161716v1edeecex3fe947ffe107770d@mail.gmail.com> Message-ID: <499A131F.2000109@softsynth.com> Please use a new subject when changing topics. > ...Does anybody know what happened to CSound and, what is the > most stable GUI front end for CSound? Check out the first link for "csounds.com" here: http://www.google.com/search?q=csound Thank you, Phil Burk --------------------------------------- SoftSynth, Audio Research and Development http://www.softsynth.com/ 75 Pleasant Lane, San Rafael, CA, 94901 USA Office: +1-415-453-4320 Mobile: +1-415-846-4370 FAX: +1-415-373-4428 --------------------------------------- From jsyn at music.columbia.edu Mon Feb 16 20:32:35 2009 From: jsyn at music.columbia.edu (jsyn@music.columbia.edu) Date: Mon Feb 16 20:32:46 2009 Subject: [jsyn] Pure Java-ism In-Reply-To: <20090216235504.86BAC2EA948@music.columbia.edu> References: <20090216235504.86BAC2EA948@music.columbia.edu> Message-ID: <63010A4F-F85D-47A0-8FFF-153B2B7DC1A8@panix.com> Hi Phil, Doug, Nick: Would this rewrite affect sonia in any way (I only use JSyn in Processing these days ...) I suspect not. BTW, Android is a Java platform, so you folks might like to make some nice Android apps if anyone every buys one. Good luck! "Just In Time!" -- Henry -- _____Henry_Lowengard_______jhhl@panix.com___ _____110_Fair_St_Kingston_NY_12401_USA______ _________http://www.echo.net/~jhhl/_________ __________http://www.jhhl.net_______________ From jsyn at music.columbia.edu Mon Feb 16 20:53:38 2009 From: jsyn at music.columbia.edu (jsyn@music.columbia.edu) Date: Mon Feb 16 20:53:49 2009 Subject: [jsyn] Pure Java-ism In-Reply-To: <63010A4F-F85D-47A0-8FFF-153B2B7DC1A8@panix.com> References: <20090216235504.86BAC2EA948@music.columbia.edu> <63010A4F-F85D-47A0-8FFF-153B2B7DC1A8@panix.com> Message-ID: <499A18A2.2030009@softsynth.com> Hi Henry, We will preserve the existing API. So it should not affect Sonia except that the JSyn plugin won't be required anymore. We would encourage the authors of Sonia to use the new API so users can write their own synthesis plugins. Thank you, Phil Burk --------------------------------------- SoftSynth, Audio Research and Development http://www.softsynth.com/ 75 Pleasant Lane, San Rafael, CA, 94901 USA Office: +1-415-453-4320 Mobile: +1-415-846-4370 FAX: +1-415-373-4428 --------------------------------------- jsyn@music.columbia.edu wrote: > > Hi Phil, Doug, Nick: > > Would this rewrite affect sonia in any way (I only use JSyn in > Processing these days ...) > > I suspect not. > > BTW, Android is a Java platform, so you folks might like to make some > nice Android apps if anyone every buys one. > > Good luck! "Just In Time!" > > > -- Henry > > -- > _____Henry_Lowengard_______jhhl@panix.com___ > _____110_Fair_St_Kingston_NY_12401_USA______ > _________http://www.echo.net/~jhhl/_________ > __________http://www.jhhl.net_______________ > > _______________________________________________ > JSyn mailing list > JSyn@music.columbia.edu > To change digest mode or to make other administrative changes visit: > http://music.columbia.edu/mailman/listinfo/jsyn > > From jsyn at music.columbia.edu Mon Feb 16 22:01:43 2009 From: jsyn at music.columbia.edu (jsyn@music.columbia.edu) Date: Mon Feb 16 22:01:53 2009 Subject: [jsyn] JSyn in pure Java In-Reply-To: <21659055.1234820995284.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net> References: <21659055.1234820995284.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net> Message-ID: <499A2897.5000804@softsynth.com> > But for me, if my current level of real-time, often full-duplex, > cpu intensity is going to lead to drop-outs, I'll be much bummed. I ran some benchmarks comparing the native JSyn and the new Pure Java version. The benchmark keeps loading up pairs of SineOscillators and AddUnits in a dense cloud until the sound starts to break up. I am testing on Windows XP Dual Core Athlon at 2.4 GHz. Native code max is 470 pairs before sound breaks up. Pure "java -client" max is 320 pairs. Pure "java -server" max is 400 pairs. So Java is slower but not a lot slower. And many modern benchmarks show equivalent performance. Also I plan to implement multi-threaded synthesis so we can make better use of multi-core CPUs. Synthesis can take good advantage of multiple cores if we can partition groups of unit generators that are not connected. This does not address the issue of latency. Generally, if you use lower latency then you are more prone to dropouts. If latency is critical then you may need to use the old native code. But I find that I can get pretty low latency on a Mac. It's not low enough to keep a drummer happy. But I can click around and it feels pretty responsive. Java keeps improving so I imagine there will be better real-time JVMs in the future. Check out Florian Bomers' amazing MIDI Synth experiment using IBM Java that achieved 2 msec latency. http://domino.watson.ibm.com/comm/research_projects.nsf/pages/metronome.harmonicon.html Thank you, Phil Burk --------------------------------------- SoftSynth, Audio Research and Development http://www.softsynth.com/ 75 Pleasant Lane, San Rafael, CA, 94901 USA Office: +1-415-453-4320 Mobile: +1-415-846-4370 FAX: +1-415-373-4428 --------------------------------------- jsyn@music.columbia.edu wrote: > The question for my own work would be how this move to pure Java effects real-time thruput and overall audio processing latency given applications that are now using about all the avail cpu load modern personal computers. Though I know this is very important for some and a key selling point of java in general but browser based applets aren't my world - building applications meant to be run by themselves as performance instruments on stage is (and I love Java and Jsyn). > > I do love the idea of more access to the code / unit generators (including the possibility of of more interaction with back-end threading issues etc.) and in general back-end code that is easier to support for Phil and thus runs better (and develops quicker) for all of us. > > But for me, if my current level of real-time, often full-duplex, cpu intensity is going to lead to drop-outs, I'll be much bummed. > > thanks - > > C>T> > > -----Original Message----- >> From: jsyn@music.columbia.edu >> Sent: Feb 16, 2009 4:32 PM >> To: jsyn discussion list >> Subject: [jsyn] JSyn in pure Java >> >> Yesterday I started rewriting the native part of JSyn in pure Java. >> >> As you know, the JSyn synthesis engine was written in native 'C' code. >> This was necessary in 1997 to get high fidelity audio and reasonable >> performance. In 2009 it is no longer necessary. Progress on JSyn has >> been slow these past few years, mostly because I spend most of my JSyn >> time on problems related to the native code plugin in browsers. >> >> Goals >> >> 1) Allow existing Applets to run without modification. >> >> 2) Allow old and new Applets to run in a browser without requiring a plugin. >> >> 3) Allow users to easily add their own unit generators. >> >> 4) Simplify development. >> >> 5) Support native audio interface if JavaSound not working well enough. >> >> >> How it Works >> >> I have created a new synthesis engine in a "com.jsyn" package. It will >> have an updated API using modern Java techniques and support plugins. >> >> I then modified SynthContext so that it calls the pure Java synthesizer >> through a bridge. This bridge code handles all the token and other >> weirdness that was necessary to support the native library. The old >> native synthesizer can still be called by using SynthContextNative. >> >> The old API in com.softsynth.jsyn will be frozen and new development >> made in the com.jsyn package. Developers can use either API but will be >> encouraged to move to the new API. >> >> Thoughts? Questions? Good idea? Bad idea? >> >> I will follow this with a letter describing some API changes. >> >> Thank you, >> Phil Burk >> --------------------------------------- >> SoftSynth, Audio Research and Development >> http://www.softsynth.com/ >> 75 Pleasant Lane, San Rafael, CA, 94901 USA >> Office: +1-415-453-4320 >> Mobile: +1-415-846-4370 >> FAX: +1-415-373-4428 >> --------------------------------------- >> _______________________________________________ >> JSyn mailing list >> JSyn@music.columbia.edu >> To change digest mode or to make other administrative changes visit: >> http://music.columbia.edu/mailman/listinfo/jsyn > > _______________________________________________ > JSyn mailing list > JSyn@music.columbia.edu > To change digest mode or to make other administrative changes visit: > http://music.columbia.edu/mailman/listinfo/jsyn > > From jsyn at music.columbia.edu Mon Feb 16 22:04:35 2009 From: jsyn at music.columbia.edu (jsyn@music.columbia.edu) Date: Mon Feb 16 22:04:48 2009 Subject: [jsyn] JSyn in pure Java In-Reply-To: <4999DB84.20601@softsynth.com> References: <4999DB84.20601@softsynth.com> Message-ID: <11305EF1-A97A-4DEA-82FF-DC4457835A9E@asu.edu> Hi Phil, I think this sounds fantastic! We'd be happy to do some beta testing if that would be helpful. /david On Feb 16, 2009, at 2:32 PM, wrote: > Yesterday I started rewriting the native part of JSyn in pure Java. > > As you know, the JSyn synthesis engine was written in native 'C' > code. This was necessary in 1997 to get high fidelity audio and > reasonable performance. In 2009 it is no longer necessary. Progress > on JSyn has been slow these past few years, mostly because I spend > most of my JSyn time on problems related to the native code plugin > in browsers. > > Goals > > 1) Allow existing Applets to run without modification. > > 2) Allow old and new Applets to run in a browser without requiring a > plugin. > > 3) Allow users to easily add their own unit generators. > > 4) Simplify development. > > 5) Support native audio interface if JavaSound not working well > enough. > > > How it Works > > I have created a new synthesis engine in a "com.jsyn" package. It > will have an updated API using modern Java techniques and support > plugins. > > I then modified SynthContext so that it calls the pure Java > synthesizer through a bridge. This bridge code handles all the token > and other weirdness that was necessary to support the native > library. The old native synthesizer can still be called by using > SynthContextNative. > > The old API in com.softsynth.jsyn will be frozen and new development > made in the com.jsyn package. Developers can use either API but will > be encouraged to move to the new API. > > Thoughts? Questions? Good idea? Bad idea? > > I will follow this with a letter describing some API changes. > > Thank you, > Phil Burk > --------------------------------------- > SoftSynth, Audio Research and Development > http://www.softsynth.com/ > 75 Pleasant Lane, San Rafael, CA, 94901 USA > Office: +1-415-453-4320 > Mobile: +1-415-846-4370 > FAX: +1-415-373-4428 > --------------------------------------- > _______________________________________________ > JSyn mailing list > JSyn@music.columbia.edu > To change digest mode or to make other administrative changes visit: > http://music.columbia.edu/mailman/listinfo/jsyn From jsyn at music.columbia.edu Tue Feb 17 01:45:08 2009 From: jsyn at music.columbia.edu (jsyn@music.columbia.edu) Date: Tue Feb 17 01:45:24 2009 Subject: [jsyn] JSyn in pure Java In-Reply-To: <20090216224642.2619D2EA13D@music.columbia.edu> References: <20090216224642.2619D2EA13D@music.columbia.edu> Message-ID: <2C59C7AE540AE24BBEE49A223ECD623071C0F087FD@EXCHCCRMAILBOX.ewation.co.za> Hi Phil, This is good news, will the Pure Java version of Jsyn still have support for the Multi Channel hardware like Terratec or "Terrasonic". James This E-mail and any attachment(s) to it are for the addressee's use only. It is strictly confidential and may contain legally privileged information. No confidentiality or privilege is waived or lost by any mis-transmission. If you are not the intended addressee, then please delete it from your system and notify the sender immediately. You are hereby notified that any use, disclosure, copying or any action taken in reliance on it is strictly prohibited and may be unlawful. From jsyn at music.columbia.edu Tue Feb 17 11:16:50 2009 From: jsyn at music.columbia.edu (jsyn@music.columbia.edu) Date: Tue Feb 17 11:22:18 2009 Subject: [jsyn] JSyn in pure Java In-Reply-To: <4999DB84.20601@softsynth.com> References: <4999DB84.20601@softsynth.com> Message-ID: <8CB5F3245A282BE-1290-9D@webmail-mf18.sysops.aol.com> Hi Phil, This is very good news. The existing "plugin download" is death for me. Even if it ran only on Java 1.6 that would be OK. John Clavin -----Original Message----- From: jsyn@music.columbia.edu To: jsyn discussion list Sent: Mon, 16 Feb 2009 1:32 pm Subject: [jsyn] JSyn in pure Java Yesterday I started rewriting the native part of JSyn in pure Java.? ? As you know, the JSyn synthesis engine was written in native 'C' code. This was necessary in 1997 to get high fidelity audio and reasonable performance. In 2009 it is no longer necessary. Progress on JSyn has been slow these past few years, mostly because I spend most of my JSyn time on problems related to the native code plugin in browsers.? ? Goals? ? 1) Allow existing Applets to run without modification.? ? 2) Allow old and new Applets to run in a browser without requiring a plugin.? ? 3) Allow users to easily add their own unit generators.? ? 4) Simplify development.? ? 5) Support native audio interface if JavaSound not working well enough.? ? How it Works? ? I have created a new synthesis engine in a "com.jsyn" package. It will have an updated API using modern Java techniques and support plugins.? ? I then modified SynthContext so that it calls the pure Java synthesizer through a bridge. This bridge code handles all the token and other weirdness that was necessary to support the native library. The old native synthesizer can still be called by using SynthContextNative.? ? The old API in com.softsynth.jsyn will be frozen and new development made in the com.jsyn package. Developers can use either API but will be encouraged to move to the new API.? ? Thoughts? Questions? Good idea? Bad idea?? ? I will follow this with a letter describing some API changes.? ? Thank you,? Phil Burk? ---------------------------------------? SoftSynth, Audio Research and Development? http://www.softsynth.com/? 75 Pleasant Lane, San Rafael, CA, 94901 USA? Office: +1-415-453-4320? Mobile: +1-415-846-4370? FAX: +1-415-373-4428? ---------------------------------------? _______________________________________________? JSyn mailing list? JSyn@music.columbia.edu? To change digest mode or to make other administrative changes visit:? http://music.columbia.edu/mailman/listinfo/jsyn? From jsyn at music.columbia.edu Tue Feb 17 11:36:06 2009 From: jsyn at music.columbia.edu (jsyn@music.columbia.edu) Date: Tue Feb 17 11:37:01 2009 Subject: [jsyn] JSyn in pure Java In-Reply-To: <499A2897.5000804@softsynth.com> References: <21659055.1234820995284.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net> <499A2897.5000804@softsynth.com> Message-ID: <8CB5F34F754652C-1290-204@webmail-mf18.sysops.aol.com> >I ran some benchmarks comparing the native JSyn and the new Pure Java version.? Which version of Java? The graphic program "Processing" runs much faster with Java 1.6. Could this affect Jsyn Pure?Java? John Clavin -----Original Message----- From: jsyn@music.columbia.edu To: jsyn@music.columbia.edu Sent: Mon, 16 Feb 2009 7:01 pm Subject: Re: [jsyn] JSyn in pure Java > But for me, if my current level of real-time, often full-duplex,? > cpu intensity is going to lead to drop-outs, I'll be much bummed.? ? I ran some benchmarks comparing the native JSyn and the new Pure Java version.? ? The benchmark keeps loading up pairs of SineOscillators and AddUnits in a dense cloud until the sound starts to break up.? ? I am testing on Windows XP Dual Core Athlon at 2.4 GHz.? ? Native code max is 470 pairs before sound breaks up.? ? Pure "java -client" max is 320 pairs.? ? Pure "java -server" max is 400 pairs.? ? So Java is slower but not a lot slower. And many modern benchmarks show equivalent performance. Also I plan to implement multi-threaded synthesis so we can make better use of multi-core CPUs. Synthesis can take good advantage of multiple cores if we can partition groups of unit generators that are not connected.? ? This does not address the issue of latency. Generally, if you use lower latency then you are more prone to dropouts.? ? If latency is critical then you may need to use the old native code. But I find that I can get pretty low latency on a Mac. It's not low enough to keep a drummer happy. But I can click around and it feels pretty responsive.? ? Java keeps improving so I imagine there will be better real-time JVMs in the future.? ? Check out Florian Bomers' amazing MIDI Synth experiment using IBM Java that achieved 2 msec latency.? ? http://domino.watson.ibm.com/comm/research_projects.nsf/pages/metronome.harmonicon.html? ? Thank you,? Phil Burk? ---------------------------------------? SoftSynth, Audio Research and Development? http://www.softsynth.com/? 75 Pleasant Lane, San Rafael, CA, 94901 USA? Office: +1-415-453-4320? Mobile: +1-415-846-4370? FAX: +1-415-373-4428? ---------------------------------------? ? jsyn@music.columbia.edu wrote:? > The question for my own work would be how this move to pure Java effects real-time thruput and overall audio processing latency given applications that are now using about all the avail cpu load modern personal computers. Though I know this is very important for some and a key selling point of java in general but browser based applets aren't my world - building applications meant to be run by themselves as performance instruments on stage is (and I love Java and Jsyn).? > > I do love the idea of more access to the code / unit generators (including the possibility of of more interaction with back-end threading issues etc.) and in general back-end code that is easier to support for Phil and thus runs better (and develops quicker) for all of us.? > > But for me, if my current level of real-time, often full-duplex, cpu intensity is going to lead to drop-outs, I'll be much bummed.? > > thanks -? > > C>T>? > > -----Original Message-----? >> From: jsyn@music.columbia.edu? >> Sent: Feb 16, 2009 4:32 PM? >> To: jsyn discussion list ? >> Subject: [jsyn] JSyn in pure Java? >>? >> Yesterday I started rewriting the native part of JSyn in pure Java.? >>? >> As you know, the JSyn synthesis engine was written in native 'C' code. >> This was necessary in 1997 to get high fidelity audio and reasonable >> performance. In 2009 it is no longer necessary. Progress on JSyn has >> been slow these past few years, mostly because I spend most of my JSyn >> time on problems related to the native code plugin in browsers.? >>? >> Goals? >>? >> 1) Allow existing Applets to run without modification.? >>? >> 2) Allow old and new Applets to run in a browser without requiring a plugin.? >>? >> 3) Allow users to easily add their own unit generators.? >>? >> 4) Simplify development.? >>? >> 5) Support native audio interface if JavaSound not working well enough.? >>? >>? >> How it Works? >>? >> I have created a new synthesis engine in a "com.jsyn" package. It will >> have an updated API using modern Java techniques and support plugins.? >>? >> I then modified SynthContext so that it calls the pure Java synthesizer >> through a bridge. This bridge code handles all the token and other >> weirdness that was necessary to support the native library. The old >> native synthesizer can still be called by using SynthContextNative.? >>? >> The old API in com.softsynth.jsyn will be frozen and new development >> made in the com.jsyn package. Developers can use either API but will be >> encouraged to move to the new API.? >>? >> Thoughts? Questions? Good idea? Bad idea?? >>? >> I will follow this with a letter describing some API changes.? >>? >> Thank you,? >> Phil Burk? >> ---------------------------------------? >> SoftSynth, Audio Research and Development? >> http://www.softsynth.com/? >> 75 Pleasant Lane, San Rafael, CA, 94901 USA? >> Office: +1-415-453-4320? >> Mobile: +1-415-846-4370? >> FAX: +1-415-373-4428? >> ---------------------------------------? >> _______________________________________________? >> JSyn mailing list? >> JSyn@music.columbia.edu? >> To change digest mode or to make other administrative changes visit:? >> http://music.columbia.edu/mailman/listinfo/jsyn? > > _______________________________________________? > JSyn mailing list? > JSyn@music.columbia.edu? > To change digest mode or to make other administrative changes visit:? > http://music.columbia.edu/mailman/listinfo/jsyn? > > _______________________________________________? JSyn mailing list? JSyn@music.columbia.edu? To change digest mode or to make other administrative changes visit:? http://music.columbia.edu/mailman/listinfo/jsyn? From jsyn at music.columbia.edu Tue Feb 17 13:09:56 2009 From: jsyn at music.columbia.edu (jsyn@music.columbia.edu) Date: Tue Feb 17 13:10:05 2009 Subject: [jsyn] JSyn in pure Java In-Reply-To: <2C59C7AE540AE24BBEE49A223ECD623071C0F087FD@EXCHCCRMAILBOX.ewation.co.za> References: <20090216224642.2619D2EA13D@music.columbia.edu> <2C59C7AE540AE24BBEE49A223ECD623071C0F087FD@EXCHCCRMAILBOX.ewation.co.za> Message-ID: <499AFD74.4000509@softsynth.com> Hello James, > This is good news, will the Pure Java version of Jsyn > still have support for the Multi Channel hardware like > Terratec or "Terrasonic". There will be three ways that multi-channel devices will be supported: 1) Through the old native 'C' engine. 2) Though the pure Java code if JavaSound supports multi-channel devices. 3) Through the new Java engine and a low level audio interface if needed. The low level audio interface will be developed using PortAudio to support devices that JavaSound does not support. On Macs, for example, FireWire audio does not work well. Thank you, Phil Burk --------------------------------------- SoftSynth, Audio Research and Development http://www.softsynth.com/ 75 Pleasant Lane, San Rafael, CA, 94901 USA Office: +1-415-453-4320 Mobile: +1-415-846-4370 FAX: +1-415-373-4428 --------------------------------------- jsyn@music.columbia.edu wrote: > Hi Phil, > > This is good news, will the Pure Java version of Jsyn still have support for > the Multi Channel hardware like Terratec or "Terrasonic". > > James > > This E-mail and any attachment(s) to it are for the addressee's use only. > It is strictly confidential and may contain legally privileged information. No confidentiality or privilege is waived or lost by any mis-transmission. If you are not the intended addressee, then please delete it from your system and notify the sender immediately. You are hereby notified that any use, disclosure, copying or any action taken in reliance on it is strictly prohibited and may be unlawful. > _______________________________________________ > JSyn mailing list > JSyn@music.columbia.edu > To change digest mode or to make other administrative changes visit: > http://music.columbia.edu/mailman/listinfo/jsyn > > From jsyn at music.columbia.edu Tue Feb 17 14:45:35 2009 From: jsyn at music.columbia.edu (jsyn@music.columbia.edu) Date: Tue Feb 17 14:45:47 2009 Subject: [jsyn] JSyn in pure Java In-Reply-To: <8CB5F34F754652C-1290-204@webmail-mf18.sysops.aol.com> References: <21659055.1234820995284.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net> <499A2897.5000804@softsynth.com> <8CB5F34F754652C-1290-204@webmail-mf18.sysops.aol.com> Message-ID: <499B13DF.6010704@softsynth.com> I used Java 1.6.0_11 for the benchmarks. Also, I had not realized that "java -server" was much faster than "java -client". I just saw the tip online but am not sure of the ramifications. Server mode Java can be used for desktop JSyn but I assume it will not work for browsers. Here is some interesting discussion: http://stackoverflow.com/questions/198577/real-differences-between-java-server-and-java-client Thank you, Phil Burk --------------------------------------- SoftSynth, Audio Research and Development http://www.softsynth.com/ 75 Pleasant Lane, San Rafael, CA, 94901 USA Office: +1-415-453-4320 Mobile: +1-415-846-4370 FAX: +1-415-373-4428 --------------------------------------- jsyn@music.columbia.edu wrote: >> I ran some benchmarks comparing the native JSyn and the new Pure Java version.? > > Which version of Java? > > The graphic program "Processing" runs much faster with Java 1.6. > > Could this affect Jsyn Pure?Java? > > John Clavin > > > -----Original Message----- > From: jsyn@music.columbia.edu > To: jsyn@music.columbia.edu > Sent: Mon, 16 Feb 2009 7:01 pm > Subject: Re: [jsyn] JSyn in pure Java > > >> But for me, if my current level of real-time, often full-duplex,? >> cpu intensity is going to lead to drop-outs, I'll be much bummed.? > ? > I ran some benchmarks comparing the native JSyn and the new Pure Java version.? > ? > The benchmark keeps loading up pairs of SineOscillators and AddUnits in a dense cloud until the sound starts to break up.? > ? > I am testing on Windows XP Dual Core Athlon at 2.4 GHz.? > ? > Native code max is 470 pairs before sound breaks up.? > ? > Pure "java -client" max is 320 pairs.? > ? > Pure "java -server" max is 400 pairs.? > ? > So Java is slower but not a lot slower. And many modern benchmarks show equivalent performance. Also I plan to implement multi-threaded synthesis so we can make better use of multi-core CPUs. Synthesis can take good advantage of multiple cores if we can partition groups of unit generators that are not connected.? > ? > This does not address the issue of latency. Generally, if you use lower latency then you are more prone to dropouts.? > ? > If latency is critical then you may need to use the old native code. But I find that I can get pretty low latency on a Mac. It's not low enough to keep a drummer happy. But I can click around and it feels pretty responsive.? > ? > Java keeps improving so I imagine there will be better real-time JVMs in the future.? > ? > Check out Florian Bomers' amazing MIDI Synth experiment using IBM Java that achieved 2 msec latency.? > ? > http://domino.watson.ibm.com/comm/research_projects.nsf/pages/metronome.harmonicon.html? > ? > Thank you,? > Phil Burk? > ---------------------------------------? > SoftSynth, Audio Research and Development? > http://www.softsynth.com/? > 75 Pleasant Lane, San Rafael, CA, 94901 USA? > Office: +1-415-453-4320? > Mobile: +1-415-846-4370? > FAX: +1-415-373-4428? > ---------------------------------------? > ? > jsyn@music.columbia.edu wrote:? >> The question for my own work would be how this move to pure Java effects real-time thruput and overall audio processing latency given applications that are now using about all the avail cpu load modern personal computers. Though I know this is very important for some and a key selling point of java in general but browser based applets aren't my world - building applications meant to be run by themselves as performance instruments on stage is (and I love Java and Jsyn).? >>> I do love the idea of more access to the code / unit generators (including the possibility of of more interaction with back-end threading issues etc.) and in general back-end code that is easier to support for Phil and thus runs better (and develops quicker) for all of us.? >>> But for me, if my current level of real-time, often full-duplex, cpu intensity is going to lead to drop-outs, I'll be much bummed.? >>> thanks -? >>> C>T>? >>> -----Original Message-----? >>> From: jsyn@music.columbia.edu? >>> Sent: Feb 16, 2009 4:32 PM? >>> To: jsyn discussion list ? >>> Subject: [jsyn] JSyn in pure Java? >>> ? >>> Yesterday I started rewriting the native part of JSyn in pure Java.? >>> ? >>> As you know, the JSyn synthesis engine was written in native 'C' code. >> This was necessary in 1997 to get high fidelity audio and reasonable >> performance. In 2009 it is no longer necessary. Progress on JSyn has >> been slow these past few years, mostly because I spend most of my JSyn >> time on problems related to the native code plugin in browsers.? >>> ? >>> Goals? >>> ? >>> 1) Allow existing Applets to run without modification.? >>> ? >>> 2) Allow old and new Applets to run in a browser without requiring a plugin.? >>> ? >>> 3) Allow users to easily add their own unit generators.? >>> ? >>> 4) Simplify development.? >>> ? >>> 5) Support native audio interface if JavaSound not working well enough.? >>> ? >>> ? >>> How it Works? >>> ? >>> I have created a new synthesis engine in a "com.jsyn" package. It will >> have an updated API using modern Java techniques and support plugins.? >>> ? >>> I then modified SynthContext so that it calls the pure Java synthesizer >> through a bridge. This bridge code handles all the token and other >> weirdness that was necessary to support the native library. The old >> native synthesizer can still be called by using SynthContextNative.? >>> ? >>> The old API in com.softsynth.jsyn will be frozen and new development >> made in the com.jsyn package. Developers can use either API but will be >> encouraged to move to the new API.? >>> ? >>> Thoughts? Questions? Good idea? Bad idea?? >>> ? >>> I will follow this with a letter describing some API changes.? >>> ? >>> Thank you,? >>> Phil Burk? >>> ---------------------------------------? >>> SoftSynth, Audio Research and Development? >>> http://www.softsynth.com/? >>> 75 Pleasant Lane, San Rafael, CA, 94901 USA? >>> Office: +1-415-453-4320? >>> Mobile: +1-415-846-4370? >>> FAX: +1-415-373-4428? >>> ---------------------------------------? >>> _______________________________________________? >>> JSyn mailing list? >>> JSyn@music.columbia.edu? >>> To change digest mode or to make other administrative changes visit:? >>> http://music.columbia.edu/mailman/listinfo/jsyn? >>> _______________________________________________? >> JSyn mailing list? >> JSyn@music.columbia.edu? >> To change digest mode or to make other administrative changes visit:? >> http://music.columbia.edu/mailman/listinfo/jsyn? >>> _______________________________________________? > JSyn mailing list? > JSyn@music.columbia.edu? > To change digest mode or to make other administrative changes visit:? > http://music.columbia.edu/mailman/listinfo/jsyn? > > _______________________________________________ > JSyn mailing list > JSyn@music.columbia.edu > To change digest mode or to make other administrative changes visit: > http://music.columbia.edu/mailman/listinfo/jsyn > > From jsyn at music.columbia.edu Tue Feb 17 14:53:08 2009 From: jsyn at music.columbia.edu (jsyn@music.columbia.edu) Date: Tue Feb 17 14:53:13 2009 Subject: [jsyn] JSyn in pure Java In-Reply-To: <4999DB84.20601@softsynth.com> References: <4999DB84.20601@softsynth.com> Message-ID: Phil -- This is a great idea! (from my perspective at least), for this reason in particular: > 3) Allow users to easily add their own unit generators. I've *always* wanted to do that. Probably the first project I'll attempt is to port a lot of the STK physical models, they really are fun to play with. I was able to build the Charlie Sullivan "Karplus Strong" thing by relying on a fixed sample/buffer delay between unit blocks, but if you had ever changed it all my stuff would have shifted strangely in pitch (I'm glad you never did!). I don't think there is anything quite like this extant in the world, either. I bet it will be really attractive to a lot of developers. brad http://music.columbia.edu/~brad From jsyn at music.columbia.edu Tue Feb 17 14:54:38 2009 From: jsyn at music.columbia.edu (jsyn@music.columbia.edu) Date: Tue Feb 17 14:54:43 2009 Subject: [jsyn] JSyn in pure Java In-Reply-To: <499A2897.5000804@softsynth.com> References: <21659055.1234820995284.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net> <499A2897.5000804@softsynth.com> Message-ID: <0F0D9E07-ECB5-4C22-AC64-D4CA4E55F620@columbia.edu> On Feb 16, 2009, at 10:01 PM, jsyn@music.columbia.edu wrote: > Native code max is 470 pairs before sound breaks up. > > Pure "java -client" max is 320 pairs. > > Pure "java -server" max is 400 pairs. Wow, this is really not bad. I was expecting much worse. Yay! brad http://music.columbia.edu/~brad From jsyn at music.columbia.edu Tue Feb 17 15:04:55 2009 From: jsyn at music.columbia.edu (jsyn@music.columbia.edu) Date: Tue Feb 17 15:05:05 2009 Subject: [jsyn] JSyn in pure Java In-Reply-To: <0F0D9E07-ECB5-4C22-AC64-D4CA4E55F620@columbia.edu> References: <21659055.1234820995284.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net> <499A2897.5000804@softsynth.com> <0F0D9E07-ECB5-4C22-AC64-D4CA4E55F620@columbia.edu> Message-ID: <499B1867.7060709@softsynth.com> > Wow, this is really not bad. I was expecting much worse. Yay! The new Java HotSpot recompiler/optimizers are pretty amazing. Also because of the safe and sane nature of the Java language they can sometime make optimizations that are not possible for C++ code. So in some cases Java can actually beat C++. Thank you, Phil Burk --------------------------------------- SoftSynth, Audio Research and Development http://www.softsynth.com/ 75 Pleasant Lane, San Rafael, CA, 94901 USA Office: +1-415-453-4320 Mobile: +1-415-846-4370 FAX: +1-415-373-4428 --------------------------------------- jsyn@music.columbia.edu wrote: > On Feb 16, 2009, at 10:01 PM, jsyn@music.columbia.edu wrote: > >> Native code max is 470 pairs before sound breaks up. >> >> Pure "java -client" max is 320 pairs. >> >> Pure "java -server" max is 400 pairs. > > Wow, this is really not bad. I was expecting much worse. Yay! > > brad > http://music.columbia.edu/~brad > > _______________________________________________ > JSyn mailing list > JSyn@music.columbia.edu > To change digest mode or to make other administrative changes visit: > http://music.columbia.edu/mailman/listinfo/jsyn > > From jsyn at music.columbia.edu Tue Feb 24 02:17:20 2009 From: jsyn at music.columbia.edu (jsyn@music.columbia.edu) Date: Tue Feb 24 02:17:31 2009 Subject: [jsyn] clearing scheduled events Message-ID: <28474751.1235459841491.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net> If I have an EnvelopePort and I queue data onto it, specifying a tick time in the future: myEnvelopePort.queue(futureTime, myEnvelope); and I decide later - but before futureTime - i.e. before the envelope has been queued, I want to stop this event from happening is there a way to do this? EnvelopePort.clear() isn't working (I think) because the data has not been queued yet. In short, is there a way I can remove events I add to the scheduler? thanks - C>T> From jsyn at music.columbia.edu Tue Feb 24 13:09:43 2009 From: jsyn at music.columbia.edu (jsyn@music.columbia.edu) Date: Tue Feb 24 13:10:03 2009 Subject: [jsyn] clearing scheduled events In-Reply-To: <28474751.1235459841491.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net> References: <28474751.1235459841491.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net> Message-ID: <49A437E7.8070103@softsynth.com> Hello C>T> In my last letter I said there was no way to clear scheduled events. But for envelopes you can queue data in a way that will flush anything else left in the queue. That might help. Use this flag: http://www.softsynth.com/jsyn/docs/autodocs/com/softsynth/jsyn/Synth.html#FLAG_SKIP_IF_OTHERS when calling: envPlayer.envelopePort.queue( envelope, startFrame, numFrames, flags) Thank you, Phil Burk --------------------------------------- SoftSynth, Audio Research and Development http://www.softsynth.com/ 75 Pleasant Lane, San Rafael, CA, 94901 USA Office: +1-415-453-4320 Mobile: +1-415-846-4370 FAX: +1-415-373-4428 --------------------------------------- jsyn@music.columbia.edu wrote: > If I have an EnvelopePort and I queue data onto it, specifying a tick time in the future: > > myEnvelopePort.queue(futureTime, myEnvelope); > > and I decide later - but before futureTime - i.e. before the envelope has been queued, I want to stop this event from happening is there a way to do this? EnvelopePort.clear() isn't working (I think) because the data has not been queued yet. > > In short, is there a way I can remove events I add to the scheduler? > > thanks - > > C>T> > _______________________________________________ > JSyn mailing list > JSyn@music.columbia.edu > To change digest mode or to make other administrative changes visit: > http://music.columbia.edu/mailman/listinfo/jsyn > > From jsyn at music.columbia.edu Tue Feb 24 12:58:23 2009 From: jsyn at music.columbia.edu (jsyn@music.columbia.edu) Date: Tue Feb 24 13:16:55 2009 Subject: [jsyn] clearing scheduled events In-Reply-To: <28474751.1235459841491.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net> References: <28474751.1235459841491.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net> Message-ID: <49A4353F.5080308@softsynth.com> Hello, There is currently no way to clear events that have been posted to the event buffer. It is best to only schedule events for the near future when you know for certain you want them to occur. I have been thinking of adding synthContext.clearScheduledEvents() and will do that for the pure Java implementation. Thank you, Phil Burk --------------------------------------- SoftSynth, Audio Research and Development http://www.softsynth.com/ 75 Pleasant Lane, San Rafael, CA, 94901 USA Office: +1-415-453-4320 Mobile: +1-415-846-4370 FAX: +1-415-373-4428 --------------------------------------- jsyn@music.columbia.edu wrote: > If I have an EnvelopePort and I queue data onto it, specifying a tick time in the future: > > myEnvelopePort.queue(futureTime, myEnvelope); > > and I decide later - but before futureTime - i.e. before the envelope has been queued, I want to stop this event from happening is there a way to do this? EnvelopePort.clear() isn't working (I think) because the data has not been queued yet. > > In short, is there a way I can remove events I add to the scheduler? > > thanks - > > C>T> > _______________________________________________ > JSyn mailing list > JSyn@music.columbia.edu > To change digest mode or to make other administrative changes visit: > http://music.columbia.edu/mailman/listinfo/jsyn > > From jsyn at music.columbia.edu Tue Feb 24 14:00:53 2009 From: jsyn at music.columbia.edu (jsyn@music.columbia.edu) Date: Tue Feb 24 14:01:36 2009 Subject: [jsyn] clearing scheduled events Message-ID: <7720049.1235502054941.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net> thanks, Phil. > >I have been thinking of adding synthContext.clearScheduledEvents() and >will do that for the pure Java implementation. > that would be useful. what about the possibility of getting event id's on return of scheduling events and being able to later remove individual events using their ids? C>T> From jsyn at music.columbia.edu Tue Feb 24 14:53:50 2009 From: jsyn at music.columbia.edu (jsyn@music.columbia.edu) Date: Tue Feb 24 14:54:09 2009 Subject: [jsyn] clearing scheduled events In-Reply-To: <7720049.1235502054941.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net> References: <7720049.1235502054941.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net> Message-ID: <49A4504E.7050602@softsynth.com> That could work. Is that preferable to just clearing all events? You would have to keep track of these events. Thank you, Phil Burk --------------------------------------- SoftSynth, Audio Research and Development http://www.softsynth.com/ 75 Pleasant Lane, San Rafael, CA, 94901 USA Office: +1-415-453-4320 Mobile: +1-415-846-4370 FAX: +1-415-373-4428 --------------------------------------- jsyn@music.columbia.edu wrote: > thanks, Phil. > >> I have been thinking of adding synthContext.clearScheduledEvents() and >> will do that for the pure Java implementation. >> > > that would be useful. what about the possibility of getting event id's on return of scheduling events and being able to later remove individual events using their ids? > > C>T> > > _______________________________________________ > JSyn mailing list > JSyn@music.columbia.edu > To change digest mode or to make other administrative changes visit: > http://music.columbia.edu/mailman/listinfo/jsyn > > From jsyn at music.columbia.edu Tue Feb 24 15:48:31 2009 From: jsyn at music.columbia.edu (jsyn@music.columbia.edu) Date: Tue Feb 24 15:48:40 2009 Subject: [jsyn] clearing scheduled events Message-ID: <12841894.1235508513057.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net> seems like it would be much more flexible and not too big a deal to hash events as needed although and= additional clear all may also come in quite handy if possible - C>T> -----Original Message----- >From: jsyn@music.columbia.edu >Sent: Feb 24, 2009 2:53 PM >To: "jsyn@music.columbia.edu" >Subject: Re: [jsyn] clearing scheduled events > >That could work. Is that preferable to just clearing all events? You >would have to keep track of these events. > >Thank you, >Phil Burk >--------------------------------------- >SoftSynth, Audio Research and Development >http://www.softsynth.com/ >75 Pleasant Lane, San Rafael, CA, 94901 USA >Office: +1-415-453-4320 >Mobile: +1-415-846-4370 >FAX: +1-415-373-4428 >--------------------------------------- > > >jsyn@music.columbia.edu wrote: >> thanks, Phil. >> >>> I have been thinking of adding synthContext.clearScheduledEvents() and >>> will do that for the pure Java implementation. >>> >> >> that would be useful. what about the possibility of getting event id's on return of scheduling events and being able to later remove individual events using their ids? >> >> C>T> >> >> _______________________________________________ >> JSyn mailing list >> JSyn@music.columbia.edu >> To change digest mode or to make other administrative changes visit: >> http://music.columbia.edu/mailman/listinfo/jsyn >> >> >_______________________________________________ >JSyn mailing list >JSyn@music.columbia.edu >To change digest mode or to make other administrative changes visit: >http://music.columbia.edu/mailman/listinfo/jsyn