You can subscribe to this list here.
2005 |
Jan
|
Feb
|
Mar
(3) |
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
2007 |
Jan
(1) |
Feb
(2) |
Mar
(10) |
Apr
(7) |
May
(4) |
Jun
|
Jul
(5) |
Aug
(20) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
(1) |
Aug
|
Sep
|
Oct
(13) |
Nov
|
Dec
|
2009 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
From: <kos...@gm...> - 2011-12-11 06:12:56
|
Ok, somehow a new installation solved my problem, maybe setting a path for fts.exe solved it, i dunno Still can't configure the whole thing, I guess portaudio will help, but not today... ANYONE here? -------- Original-Nachricht -------- > Datum: Sat, 10 Dec 2011 13:24:39 +0100 > Von: kos...@gm... > An: "jmax-user " <jma...@li...> > Betreff: [jmax-user] (no subject) > Anyone here who still uses the old Win32 Beta on XP? ..... Server on > localhost doesn't start, no patcher window, files don't load... Works only for > the first time after installation, but then no soundcard is found > > > > > > > > > > > > > > > > > > > > > > > -- > NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! > Jetzt informieren: http://www.gmx.net/de/go/freephone > > ------------------------------------------------------------------------------ > Learn Windows Azure Live! Tuesday, Dec 13, 2011 > Microsoft is holding a special Learn Windows Azure training event for > developers. It will provide a great way to learn Windows Azure and what it > provides. You can attend the event by watching it streamed LIVE online. > Learn more at http://p.sf.net/sfu/ms-windowsazure > _______________________________________________ > jmax-user mailing list > jma...@li... > https://lists.sourceforge.net/lists/listinfo/jmax-user -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de |
From: <kos...@gm...> - 2011-12-10 12:20:12
|
Anyone here who still uses the old Win32 Beta on XP? ..... Server on localhost doesn't start, no patcher window, files don't load... Works only for the first time after installation, but then no soundcard is found -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone |
From: Maurizio De C. <mau...@de...> - 2009-09-14 08:24:55
|
Friday Apple announced that Grand Central Dispatch has been licensed as open source, so i took a deep look at it. GDC is a framework for concurrent programming; my opinion is that is a nice piece of work, over hyped by the Apple Marketing as usual. Essentially, it implements a small part of the standard concurrent design patterns, and pretend to have solved all the problems in concurrent programming. To have an idea of what i am talking about you can compare GDC with the work done by Prof. Doug Lea and later integrated in Java as the java.util.concurrent package. But, if we leave out the marketing, and look to the essentials, the interesting part is: 1) it implements exactly the design patterns i need to make jMax multi-threaded synchronized queues and thread pools). 2) it is extremely easy to put in place. 3) it is kernel optimized. So, i am seriously consider using it to make the multi-threaded version of jMax, depending on the community reactions and its availability on Linux. By the way, the Mac OS X porting activity is going on. I am able today to compile all the code, all the needed pieces are there, including portaudio, portmidi and the SGI audiofile library (that we well substitute in the future, but that is needed today) and i need to fix the linking commands to complete the build. Maurizio -- Music: http://www.myspace.com/mauriziodececco Blog: http://maurizio.dececco.name/ Software: http://www.jmax-phoenix.org/ |
From: Maurizio De C. <mau...@de...> - 2009-04-16 13:04:46
|
[Feel free to forward this announce anywhere you find appropriate] The reports of the jMax death have been greatly exaggerated. Free software never dies, it just sleeps for some time. Almost nine years after the release of the project under a free license, and six years after the end of the developments by the institution that created it, some of the original project developers decided to revive it from its ashes: jMax Phoenix was born. JMax is a community project, not controlled by a single institution; it was Started from some of the original jMax developers in the summer of 2008. The project priorities are to give jMax a modern User interface, to integrate it into the modern Linux audio environment, and, last but not least, scalability. Detailed plans for the projects are presented in these days at the Linux audio conference 2009 in Parma. Check the proceedings for more information. We are looking for, core developers (C, Objective C, Java, Swing), object developers (DSP, Control), porevelopers to port existing libraries, testers and early users, and a graphic designer. Please not that the jMax Phoenix project is a fork of the original code base and cvs. For those who know the jMax history, jMax Phoenix started from jMax 2.4.5. Later developments will be backported if judged interesting. The developments are today focused on the user interface: more than one third of the code has been rewritten, and the rest heavily modified to provide an interface aligned with modern standards. The project home page is http://www.jmax-phoenix.org, where you can find the main page and a wiki including user documentation and design documents. The project team can be contacted at co...@jm.... The project sources and mailing lists are hosted by sourceforge, at http://sourceforge.net/projects/jmax-phoenix/; please, join the developers mailing list to follows the project evolutions, give your opinions or express your needs. You’ll find snapshot binary releases on the sourceforge site; they are versioned using the subversion revision number; these snapshots are not yet supposed to be stable or fully functional, but they currently give a pretty good idea of the evolution of the user interface. The user documentation in the wiki will be kept consistent with the last snapshot released. JMax Phoenix is release under the original jMax license, GPL with an exception for loaded package, and the is copyrighted either by Maurizio De Cecco, François Dechelle and Enzo Maggi, or by Ircam, or by both set of authors. Hoping to see you on the jMax mailing list. The project team (Maurizio, François and Enzo). -- Music: http://www.myspace.com/mauriziodececco Blog: http://maurizio.dececco.name/ Software: http://www.jmax-phoenix.org/ |
From: Maurizio De C. <mau...@de...> - 2009-04-16 11:13:10
|
[Feel free to forward this announce anywhere you find appropriate] The reports of the jMax death have been greatly exaggerated. Free software never dies, it just sleeps for some time. Almost nine years after the release of the project under a free license, and six years after the end of the developments by the institution that created it, some of the original project developers decided to revive it from its ashes: jMax Phoenix was born. JMax is a community project, not controlled by a single institution; it was Started from some of the original jMax developers in the summer of 2008. The project priorities are to give jMax a modern User interface, to integrate it into the modern Linux audio environment, and, last but not least, scalability. Detailed plans for the projects are presented in these days at the Linux audio conference 2009 in Parma. Check the proceedings for more information. We are looking for, core developers (C, Objective C, Java, Swing), object developers (DSP, Control), porevelopers to port existing libraries, testers and early users, and a graphic designer. Please not that the jMax Phoenix project is a fork of the original code base and cvs. For those who know the jMax history, jMax Phoenix started from jMax 2.4.5. Later developments will be backported if judged interesting. The developments are today focused on the user interface: more than one third of the code has been rewritten, and the rest heavily modified to provide an interface aligned with modern standards. The project home page is http://www.jmax-phoenix.org, where you can find the main page and a wiki including user documentation and design documents. The project team can be contacted at co...@jm.... The project sources and mailing lists are hosted by sourceforge, at http://sourceforge.net/projects/jmax-phoenix/; please, join the developers mailing list to follows the project evolutions, give your opinions or express your needs. You’ll find snapshot binary releases on the sourceforge site; they are versioned using the subversion revision number; these snapshots are not yet supposed to be stable or fully functional, but they currently give a pretty good idea of the evolution of the user interface. The user documentation in the wiki will be kept consistent with the last snapshot released. JMax Phoenix is release under the original jMax license, GPL with an exception for loaded package, and the is copyrighted either by Maurizio De Cecco, François Dechelle and Enzo Maggi, or by Ircam, or by both set of authors. Hoping to see you on the jMax mailing list. The project team (Maurizio, François and Enzo). -- Music: http://www.myspace.com/mauriziodececco Blog: http://maurizio.dececco.name/ Software: http://www.jmax-phoenix.org/ |
From: Maurizio De C. <mau...@de...> - 2008-10-09 15:17:31
|
> I found the jmax-phoenix project on sf.net. I will join the mailing- > list there. > > Forget about my google groups idea. Well, if one day we have thousands of users, then google groups can be a good idea :->. > I am happy that jMax is alive again. On our side we are having our > first coding days to prepare for the protocole between rubyk planets > (processors) and satellites (interface) . I'll let you know what ideas > we come up with. We are looking for something that could be very > minimal in order to use custom hardware (even microphones) as > satellites. My understanding is that the protocols are intended to move signals around, not only control. If this is true, i strongly suggest you to look at the existing protocols for sound, on the Internet side (RTP, etc), and on the audio professional side (networked jack, and so on). If you talk about special hardware, than take also a look to protocols to move audio on USB and firewire, this may come usefull. > For the screenshots, maybe you could post them on your blog (http://maurizio.dececco.name/ > ) because the quality is so low I hardly see what is happening.. This is a very good idea, but i'll do it later, when the look will be polished a bit and when a real browser will exists. > By the way, how does the java interface communicate with the C engine > (type of connection, information format) ? In jMax (and this do not change in jMax phoenix) the Java UI and the C engine communicate by any available byte stream; the current implementation support TCP connections, UDP data stream, and a Unix Pipe between the two, but the protocol layer is independent from the physical connection, so you can accomadate other channels. The data format is very specific to jMax: essentially there is a basic formatting for jMax types (the atoms) and a format to send messages in the two directions; the set of possible messages is predefined, and on each side a small message interpreter act on the received message. Basic messages allows the creation/deletion of objects and connections, system commands as load a file, editing messages like describing an object to the user interface, and property value updates. A couple of things are important: the protocol is completely asynchronious, messages are freely sent in the two directions and there are no synchronisation point at the protocol level; the other thing is that the user interface do not know the whole content of the C engine, but only the things that are actually editable on a open window. Hope this help, Maurizio > > Good luck ! > > Gaspard > >> Hallo everybody, >> >> a few month ago i asked in these lists (jmax dev and users) if >> anybody could >> be interested in a revived jMax, and we had a few interesting >> discussions. >> >> Even we still far from the first public release, i think it is the >> moment to inform >> you about what is going on. >> >> Essentially, the developpement of jMax is restarted; a few point to >> notice: >> >> - There is no institution behind, this time is a community project, >> that >> i am coordinating >> for my own fun. >> >> - It is a fork; i restarted from the jMax i know and i contributed >> to >> write (version 2.x), because >> i don't necessarly approve the evolutions of further versions. I do >> not >> want ties with the jMax cvs, that >> is still owned and maintained by Ircam, so i did a fork. >> >> - The project is called jMax Phoenix, and it is hosted on source >> forge. >> The sources are stored on >> subversion and you are free to check them out and compile. >> >> - The team, for the moment, is composed by me (Maurizio De Cecco) and >> other two members of the >> original jMax team (Enzo Maggi and Fran?ois Dechelle). >> >> The current development strategy is the following: at the moment, we >> cannot play catch-up with the >> other members of the Max application family in terms of objects and >> patch libraries; we think instead that >> we should leverage the strength of the jMax architecture to show, in a >> reasonable time, what jMax can do that >> the other alternatives cannot. >> >> So, we identified two directions: innovation in the user interface, >> using the power of Swing to modernize the >> "patcher" paradigm, and innovation in the computational engine, using >> the freedom that a clear architecture give us. >> >> About the user interface, i planned to include four screenshots of the >> state of the current development, but the list is configured for >> moderating attachments bigger than 40Kb. I am afraid there is no >> actual >> moderator for the list, so the message with the screenshots will >> probably never get thru. I'll send the screenshots in four separate >> mails following this one. >> >> There is still >> a lot to do (as you see by the fake tree that is a placeholder for a >> future patch/projet browser), but the images give you an idea: >> implementing an IDE like interface for patch development. >> >> The new user interface is completely user configurable; the four >> versions you see in the screenshots are >> defined by 5 lines of script each; the first three are builtin styles, >> the fourth is an application specific interface >> built for a specific patch. Of course, the classic style (one window >> per >> patch) is still supported. >> >> Next step is a clean up of the patcher editor, getting a behaviour >> corresponding to modern UI standards. >> >> The computational engine work will follow, probably after the end of >> the >> year: we want to change the computational model from a single thread, >> one big loop, to a real multi-threaded execution that guarantee real >> time execution of the DSP computation, assuring that no degree of >> control computation or of file loading or editing operation can >> disrupt >> the sound flow, never, ever. This change will make a real integration >> with jack possible (the old jMax integration with jack did not >> followed >> the jack threading rules). >> >> If the above wake up your interest, you are free to join the jmax >> phoenix mailing lists, and if you have spare time, >> you are of course welcome as a project contributor. >> >> In particular, we are looking for: >> - Mantainers for platforms different from Linux/x86, 32 and 64 bits, >> that are the platforms we support today. >> - a graphic designer, for rebuilding a graphical identity of the >> application. >> - DSP experts, object writers, that want to write (or port) object >> libraries to jmax phoenix (including objects developped for later >> versions of jMax). >> >> Maurizio De Cecco >> jMax Phoenix project coordinator >> >> >> -- >> http://maurizio.dececco.name/ >> >> >> >> ------------------------------------------------------------------------- >> This SF.Net email is sponsored by the Moblin Your Move Developer's >> challenge >> Build the coolest Linux based applications with Moblin SDK & win >> great prizes >> Grand prize is a trip for two to an Open Source event anywhere in >> the world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> _______________________________________________ >> jmax-developer mailing list >> jma...@li... >> https://lists.sourceforge.net/lists/listinfo/jmax-developer > > > > > ------------------------------ > > Message: 3 > Date: Wed, 08 Oct 2008 20:50:34 +0200 > From: Maurizio De Cecco <mau...@de...> > Subject: [jmax-dev] jMax Phoenix > To: Discussions about using jMax <jma...@li...>, > jma...@li... > Message-ID: <48E...@de...> > Content-Type: text/plain; charset="iso-8859-1" > > Hallo everybody, > > a few month ago i asked in these lists (jmax dev and users) if anybody could > be interested in a revived jMax, and we had a few interesting discussions. > > Even we still far from the first public release, i think it is the > moment to inform > you about what is going on. > > Essentially, the developpement of jMax is restarted; a few point to notice: > > - There is no institution behind, this time is a community project, that > i am coordinating > for my own fun. > > - It is a fork; i restarted from the jMax i know and i contributed to > write (version 2.x), because > i don't necessarly approve the evolutions of further versions. I do not > want ties with the jMax cvs, that > is still owned and maintained by Ircam, so i did a fork. > > - The project is called jMax Phoenix, and it is hosted on source forge. > The sources are stored on > subversion and you are free to check them out and compile. > > - The team, for the moment, is composed by me (Maurizio De Cecco) and > other two members of the > original jMax team (Enzo Maggi and Fran?ois Dechelle). > > The current development strategy is the following: at the moment, we > cannot play catch-up with the > other members of the Max application family in terms of objects and > patch libraries; we think instead that > we should leverage the strength of the jMax architecture to show, in a > reasonable time, what jMax can do that > the other alternatives cannot. > > So, we identified two directions: innovation in the user interface, > using the power of Swing to modernize the > "patcher" paradigm, and innovation in the computational engine, using > the freedom that a clear architecture give us. > > About the user interface, i include four screenshots of the state of the > current development; there is still > a lot to do (as you see by the fake tree that is a placeholder for a > future patch/projet browser), but the images give you an idea: > implementing an IDE like interface for patch development. > > The new user interface is completely user configurable; the four > versions you see in the screenshots are > defined by 5 lines of script each; the first three are builtin styles, > the fourth is an application specific interface > built for a specific patch. Of course, the classic style (one window per > patch) is still supported. > > Next step is a clean up of the patcher editor, getting a behaviour > corresponding to modern UI standards. > > The computational engine work will follow, probably after the end of the > year: we want to change the computational model from a single thread, > one big loop, to a real multi-threaded execution that guarantee real > time execution of the DSP computation, assuring that no degree of > control computation or of file loading or editing operation can disrupt > the sound flow, never, ever. This change will make a real integration > with jack possible (the old jMax integration with jack did not followed > the jack threading rules). > > If the above wake up your interest, you are free to join the jmax > phoenix mailing lists, and if you have spare time, > you are of course welcome as a project contributor. > > In particular, we are looking for: > - Mantainers for platforms different from Linux/x86, 32 and 64 bits, > that are the platforms we support today. > - a graphic designer, for rebuilding a graphical identity of the > application. > - DSP experts, object writers, that want to write (or port) object > libraries to jmax phoenix (including objects developped for later > versions of jMax). > > Maurizio De Cecco > jMax Phoenix project coordinator > > -- http://maurizio.dececco.name/ |
From: Gaspard B. <ga...@te...> - 2008-10-08 20:15:29
|
Hi Maurizio ! Why not use google groups instead ? It's free, you have control and it works. I am happy that jMax is alive again. On our side we are having our first coding days to prepare for the protocole between rubyk planets (processors) and satellites (interface) . I'll let you know what ideas we come up with. We are looking for something that could be very minimal in order to use custom hardware (even microphones) as satellites. For the screenshots, maybe you could post them on your blog (http://maurizio.dececco.name/ ) because the quality is so low I hardly see what is happening.. By the way, how does the java interface communicate with the C engine (type of connection, information format) ? Good luck ! Gaspard > Hallo everybody, > > a few month ago i asked in these lists (jmax dev and users) if > anybody could > be interested in a revived jMax, and we had a few interesting > discussions. > > Even we still far from the first public release, i think it is the > moment to inform > you about what is going on. > > Essentially, the developpement of jMax is restarted; a few point to > notice: > > - There is no institution behind, this time is a community project, > that > i am coordinating > for my own fun. > > - It is a fork; i restarted from the jMax i know and i contributed > to > write (version 2.x), because > i don't necessarly approve the evolutions of further versions. I do > not > want ties with the jMax cvs, that > is still owned and maintained by Ircam, so i did a fork. > > - The project is called jMax Phoenix, and it is hosted on source > forge. > The sources are stored on > subversion and you are free to check them out and compile. > > - The team, for the moment, is composed by me (Maurizio De Cecco) and > other two members of the > original jMax team (Enzo Maggi and François Dechelle). > > The current development strategy is the following: at the moment, we > cannot play catch-up with the > other members of the Max application family in terms of objects and > patch libraries; we think instead that > we should leverage the strength of the jMax architecture to show, in a > reasonable time, what jMax can do that > the other alternatives cannot. > > So, we identified two directions: innovation in the user interface, > using the power of Swing to modernize the > "patcher" paradigm, and innovation in the computational engine, using > the freedom that a clear architecture give us. > > About the user interface, i planned to include four screenshots of the > state of the current development, but the list is configured for > moderating attachments bigger than 40Kb. I am afraid there is no > actual > moderator for the list, so the message with the screenshots will > probably never get thru. I'll send the screenshots in four separate > mails following this one. > > There is still > a lot to do (as you see by the fake tree that is a placeholder for a > future patch/projet browser), but the images give you an idea: > implementing an IDE like interface for patch development. > > The new user interface is completely user configurable; the four > versions you see in the screenshots are > defined by 5 lines of script each; the first three are builtin styles, > the fourth is an application specific interface > built for a specific patch. Of course, the classic style (one window > per > patch) is still supported. > > Next step is a clean up of the patcher editor, getting a behaviour > corresponding to modern UI standards. > > The computational engine work will follow, probably after the end of > the > year: we want to change the computational model from a single thread, > one big loop, to a real multi-threaded execution that guarantee real > time execution of the DSP computation, assuring that no degree of > control computation or of file loading or editing operation can > disrupt > the sound flow, never, ever. This change will make a real integration > with jack possible (the old jMax integration with jack did not > followed > the jack threading rules). > > If the above wake up your interest, you are free to join the jmax > phoenix mailing lists, and if you have spare time, > you are of course welcome as a project contributor. > > In particular, we are looking for: > - Mantainers for platforms different from Linux/x86, 32 and 64 bits, > that are the platforms we support today. > - a graphic designer, for rebuilding a graphical identity of the > application. > - DSP experts, object writers, that want to write (or port) object > libraries to jmax phoenix (including objects developped for later > versions of jMax). > > Maurizio De Cecco > jMax Phoenix project coordinator > > > -- > http://maurizio.dececco.name/ > > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win > great prizes > Grand prize is a trip for two to an Open Source event anywhere in > the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > jmax-developer mailing list > jma...@li... > https://lists.sourceforge.net/lists/listinfo/jmax-developer |
From: Gaspard B. <ga...@te...> - 2008-10-08 20:15:23
|
I found the jmax-phoenix project on sf.net. I will join the mailing- list there. Forget about my google groups idea. Gaspard ------- projects: zena CMS (http://zenadmin.org), rubyk (http://rubyk.org) |
From: Maurizio De C. <mau...@de...> - 2008-10-08 19:13:39
|
The last one. Maurizio |
From: Maurizio De C. <mau...@de...> - 2008-10-08 19:13:10
|
Maurizio |
From: Maurizio De C. <mau...@de...> - 2008-10-08 19:12:35
|
Maurizio |
From: Maurizio De C. <mau...@de...> - 2008-10-08 19:11:15
|
Beware of the extremely low jpeg quality. Mail me for the originals or for more information. Maurizio |
From: Maurizio De C. <mau...@de...> - 2008-10-08 19:03:56
|
Maurizio -- http://maurizio.dececco.name/ |
From: Maurizio De C. <mau...@de...> - 2008-10-08 19:03:43
|
Maurizio -- http://maurizio.dececco.name/ |
From: Maurizio De C. <mau...@de...> - 2008-10-08 19:03:18
|
Maurizio -- http://maurizio.dececco.name/ |
From: Maurizio De C. <mau...@de...> - 2008-10-08 19:02:50
|
Maurizio -- http://maurizio.dececco.name/ |
From: Maurizio De C. <mau...@de...> - 2008-10-08 19:02:22
|
Hallo everybody, a few month ago i asked in these lists (jmax dev and users) if anybody could be interested in a revived jMax, and we had a few interesting discussions. Even we still far from the first public release, i think it is the moment to inform you about what is going on. Essentially, the developpement of jMax is restarted; a few point to notice: - There is no institution behind, this time is a community project, that i am coordinating for my own fun. - It is a fork; i restarted from the jMax i know and i contributed to write (version 2.x), because i don't necessarly approve the evolutions of further versions. I do not want ties with the jMax cvs, that is still owned and maintained by Ircam, so i did a fork. - The project is called jMax Phoenix, and it is hosted on source forge. The sources are stored on subversion and you are free to check them out and compile. - The team, for the moment, is composed by me (Maurizio De Cecco) and other two members of the original jMax team (Enzo Maggi and François Dechelle). The current development strategy is the following: at the moment, we cannot play catch-up with the other members of the Max application family in terms of objects and patch libraries; we think instead that we should leverage the strength of the jMax architecture to show, in a reasonable time, what jMax can do that the other alternatives cannot. So, we identified two directions: innovation in the user interface, using the power of Swing to modernize the "patcher" paradigm, and innovation in the computational engine, using the freedom that a clear architecture give us. About the user interface, i planned to include four screenshots of the state of the current development, but the list is configured for moderating attachments bigger than 40Kb. I am afraid there is no actual moderator for the list, so the message with the screenshots will probably never get thru. I'll send the screenshots in four separate mails following this one. There is still a lot to do (as you see by the fake tree that is a placeholder for a future patch/projet browser), but the images give you an idea: implementing an IDE like interface for patch development. The new user interface is completely user configurable; the four versions you see in the screenshots are defined by 5 lines of script each; the first three are builtin styles, the fourth is an application specific interface built for a specific patch. Of course, the classic style (one window per patch) is still supported. Next step is a clean up of the patcher editor, getting a behaviour corresponding to modern UI standards. The computational engine work will follow, probably after the end of the year: we want to change the computational model from a single thread, one big loop, to a real multi-threaded execution that guarantee real time execution of the DSP computation, assuring that no degree of control computation or of file loading or editing operation can disrupt the sound flow, never, ever. This change will make a real integration with jack possible (the old jMax integration with jack did not followed the jack threading rules). If the above wake up your interest, you are free to join the jmax phoenix mailing lists, and if you have spare time, you are of course welcome as a project contributor. In particular, we are looking for: - Mantainers for platforms different from Linux/x86, 32 and 64 bits, that are the platforms we support today. - a graphic designer, for rebuilding a graphical identity of the application. - DSP experts, object writers, that want to write (or port) object libraries to jmax phoenix (including objects developped for later versions of jMax). Maurizio De Cecco jMax Phoenix project coordinator -- http://maurizio.dececco.name/ |
From: Maurizio De C. <mau...@de...> - 2008-10-08 18:50:58
|
Hallo everybody, a few month ago i asked in these lists (jmax dev and users) if anybody could be interested in a revived jMax, and we had a few interesting discussions. Even we still far from the first public release, i think it is the moment to inform you about what is going on. Essentially, the developpement of jMax is restarted; a few point to notice: - There is no institution behind, this time is a community project, that i am coordinating for my own fun. - It is a fork; i restarted from the jMax i know and i contributed to write (version 2.x), because i don't necessarly approve the evolutions of further versions. I do not want ties with the jMax cvs, that is still owned and maintained by Ircam, so i did a fork. - The project is called jMax Phoenix, and it is hosted on source forge. The sources are stored on subversion and you are free to check them out and compile. - The team, for the moment, is composed by me (Maurizio De Cecco) and other two members of the original jMax team (Enzo Maggi and François Dechelle). The current development strategy is the following: at the moment, we cannot play catch-up with the other members of the Max application family in terms of objects and patch libraries; we think instead that we should leverage the strength of the jMax architecture to show, in a reasonable time, what jMax can do that the other alternatives cannot. So, we identified two directions: innovation in the user interface, using the power of Swing to modernize the "patcher" paradigm, and innovation in the computational engine, using the freedom that a clear architecture give us. About the user interface, i include four screenshots of the state of the current development; there is still a lot to do (as you see by the fake tree that is a placeholder for a future patch/projet browser), but the images give you an idea: implementing an IDE like interface for patch development. The new user interface is completely user configurable; the four versions you see in the screenshots are defined by 5 lines of script each; the first three are builtin styles, the fourth is an application specific interface built for a specific patch. Of course, the classic style (one window per patch) is still supported. Next step is a clean up of the patcher editor, getting a behaviour corresponding to modern UI standards. The computational engine work will follow, probably after the end of the year: we want to change the computational model from a single thread, one big loop, to a real multi-threaded execution that guarantee real time execution of the DSP computation, assuring that no degree of control computation or of file loading or editing operation can disrupt the sound flow, never, ever. This change will make a real integration with jack possible (the old jMax integration with jack did not followed the jack threading rules). If the above wake up your interest, you are free to join the jmax phoenix mailing lists, and if you have spare time, you are of course welcome as a project contributor. In particular, we are looking for: - Mantainers for platforms different from Linux/x86, 32 and 64 bits, that are the platforms we support today. - a graphic designer, for rebuilding a graphical identity of the application. - DSP experts, object writers, that want to write (or port) object libraries to jmax phoenix (including objects developped for later versions of jMax). Maurizio De Cecco jMax Phoenix project coordinator -- http://maurizio.dececco.name/ |
From: Maurizio De C. <mau...@de...> - 2008-07-04 10:43:08
|
Hallo, is there anybody there ? I am Maurizio De Cecco, one of the initial developers of jMax. I plan, for my own fun, to restart the development of jMax. If anybody is interested or want more info, please contact me. __________ Maurizio De Cecco - http://maurizio.dececco.name/ |
From: Gaspard B. <ga...@te...> - 2008-06-23 10:28:43
|
I have been sending mails to this list without any response... I wanted to adapt jMax for an art project but could not find any help. It looks like everyone is working to create things for the commercial Max/MSP. I decided to read jMax code and start a new open source project http://rubyk.org . Rubyk is works fine in live shows I have made. I am currently waiting for funding to create a graphical interface (based on juce). If you would like to help... I am really using this tool and there are many artists around me that need a "modern" tool they can adapt. I try to document my code and test it so it should not be too hard to read. Gaspard > Hallo, > > i have been away for a few years (since june 1999), is there anybody > there that can tell me what happended :-> ? > > Maurizio De Cecco > member of the original jMax team > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > _______________________________________________ > jmax-developer mailing list > jma...@li... > https://lists.sourceforge.net/lists/listinfo/jmax-developer |
From: Maurizio De C. <mau...@de...> - 2008-06-23 09:48:17
|
Hallo, i have been away for a few years (since june 1999), is there anybody there that can tell me what happended :-> ? Maurizio De Cecco member of the original jMax team |
From: Gaspard B. <ga...@te...> - 2007-09-25 21:05:26
|
I am writing a basic processing server in Ruby to do some midi generation from pattern recognition. I thought that it could be of great value for me to understand how messages are handled within jMax so I downloaded the source code and began do read it (after sending it through Doxygen). I am currently lost. I tried to understand what happens in this simple patch: notein --- noteout This is what I have this far: 1. midi event arrives in ??? and "note_output" is called (set by "fts_midiport_add_listener") 2. the message is parsed and "fts_outlet_int" is called to set the 3 outlets 3. an "fts_atom" is created for each value and sent out with "outlet_atom" 4. the value is pushed through the list of connections into other objects: 4.1. get destination with "fts_connection_get_destination" 4.2. get input port number with "fts_connection_get_inlet" 4.3. get handler through "fts_class_get_input_handler" (dest->input_handler). Finds ??? I would greatly appreciate any insight on these two ends of the call chain (I will keep my questions on metro for later). Gaspard |
From: Diemo S. <Die...@ir...> - 2007-08-23 15:04:40
|
Hi all, you must have noticed evil spam washing up on the jmax mailing lists recently. This is because sourceforge unexplicably allows everyone to post to their lists by default. I changed this to member-only posts and removed the spam from the archives. Cheers and sorry for the inconvenience... ...Diemo -- Diemo Schwarz, PhD -- http://diemo.concatenative.net Real-Time Music Interaction Team -- http://imtr.ircam.fr IRCAM - Centre Pompidou -- 1, place Igor-Stravinsky, 75004 Paris, France Phone +33-1-4478-4879 -- Fax +33-1-4478-1540 |
From: Diemo S. <Die...@ir...> - 2006-05-23 10:26:26
|
Alan Fabian wrote: > Dear jmax-people, > > since it is possible to write java-classes for max (mxj-classes) I began > to use my java written algorithms in max. Now it is possible to program > java-classes for msp, that is helpfulk to me. > BUT I found jmax and to try it out I installed a version for MacOSX. I > am very enthusiastic about jmax. I searched for documentations and > descriptions about the architecture about jmax and my impression is, > that jmax has a java api to access fts-objects. That would mean: if I > want to program signal-objects for jmax, I need to programm fts-objects > in C. Is that right? And if so is there any possiblity to program > fts-objects in java? BECAUSE I am not really into C and even I am not > interested in C (I prefer object oriented languages like java and lisp). > If there is any possiblity in writing signal-processing objects in java > and using them in jmax I would change imediately to jmax. It is open > source and it seems to be the professional alternative to max/msp. Hi Alan, the java part of jmax concerns only the GUI. All (sound) processing is done in the FTS kernel and packages in C. For open source java media frameworks, look at JSyn and derived projects and Processing, for example... ...Diemo > jmax-developer mailing list > jma...@li... > https://lists.sourceforge.net/lists/listinfo/jmax-developer -- Diemo Schwarz, PhD -- http://www.ircam.fr/anasyn/schwarz Real-Time Applications Team -- http://www.ircam.fr/equipes/temps-reel IRCAM - Centre Pompidou -- 1, place Igor-Stravinsky, 75004 Paris, France Phone +33-1-4478-4879 -- Fax +33-1-4478-1540 |
From: Alan F. <ala...@gm...> - 2006-05-21 13:05:43
|
Dear jmax-people, since it is possible to write java-classes for max (mxj-classes) I began to use my java written algorithms in max. Now it is possible to program java-classes for msp, that is helpfulk to me. BUT I found jmax and to try it out I installed a version for MacOSX. I am very enthusiastic about jmax. I searched for documentations and descriptions about the architecture about jmax and my impression is, that jmax has a java api to access fts-objects. That would mean: if I want to program signal-objects for jmax, I need to programm fts-objects in C. Is that right? And if so is there any possiblity to program fts-objects in java? BECAUSE I am not really into C and even I am not interested in C (I prefer object oriented languages like java and lisp). If there is any possiblity in writing signal-processing objects in java and using them in jmax I would change imediately to jmax. It is open source and it seems to be the professional alternative to max/msp. Because I am very enthusiastic about jmax I hope to get some answers to my questions, thank you, Alan (Cologne/Germany) |