I agree with all points! I personally like the current style of including everything that _might_ work, and then it is up to me to finish the job if anything I need does not work. A great example is the faust2supercollider script which I would _never_ have written had it not already existed in a form that just needed updating and extension.
Maybe faust2x scripts needing attention could go into a new "tools/faust2appls/FIXME/" directory, and the README could explicitly call for volunteers! - Julius On Thu, Nov 9, 2017 at 2:03 PM, Albert Graef <aggr...@gmail.com> wrote: > What we can try to do is to assess the situation, i.e., which tools and > architectures are currently in use and which are actively maintained. Maybe > some "orphaned" architectures+tools will be adopted by new developers, > otherwise they could be moved to some kind of "attic" and still remain > available in the distribution for those who need them, but maybe not > installed by default. > > As with any open-source project of its scale and importance, there's a > tension between what users need, and what developers are capable to supply. > We all have limited time, and we like to spend it on those parts of the > system that we need the most in our own work. In order to foster Faust's > growth, we need to maintain an atmosphere where 3rd party developers' > contributions are welcomed and encouraged. Of course this means a bit less > coherence and more rough edges making things a bit harder for the users. But > I'd say that at this stage this still is to a certain extent unavoidable. > The core team maintaining the compiler and basic utilities can't possibly > know all the platforms and environments where Faust might be used, so we > heavily rely on those contributions. > > I guess that we're still looking for someone who will work on integrating > the different contributions and make them a coherent whole. Just like Romain > took it on him to pull the various bits and pieces together to produce the > new standard library. The same needs to be done for the various polyphony > implementations and, yes, the various alternative implementations for > certain popular plug-in architectures. But this doesn't just happen > overnight. We're still figuring out what's the best way to do certain > things, and we don't always agree. :) > > TL;DR: Yes, it's obviously a great topic to be discussed at the conference! > > On Thu, Nov 9, 2017 at 10:16 AM, Stéphane Letz <l...@grame.fr> wrote: >> >> Agree for a discussion at IFC sure. Note that to satisfy all people is a >> challenge, if you remove some of the faust2xxx, than *some* people will feel >> frustrated also... and so on…((-; >> >> Stéphane >> >> > Le 9 nov. 2017 à 00:53, Oliver Larkin via Faudiostream-devel >> > <faudiostream-devel@lists.sourceforge.net> a écrit : >> > >> > I think a discussion at IFC would be good (hope i can come). I know >> > people who are quite negative about faust because it seems unnecessarily >> > complicated. This is a perfect example. I know there are not enough hours >> > (and not enough devs), but simplifying things like I suggested should >> > improve the maintainability. I know faust has linux roots where people >> > probably have built up a tolerance to things not working straight a way, >> > but >> > for the less technically inclined this is quite frustrating. >> > >> > oli >> > >> > >> > >> > On Mon, Nov 6, 2017 at 11:10 AM, Stéphane Letz <l...@grame.fr> wrote: >> > Hi, >> > >> > From the several comments we’ve got, also from private mails, it seems >> > better to not do anything for now, since some people are still using older >> > faust2xxx scripts. >> > >> > Stéphane >> > >> > >> > > Le 27 oct. 2017 à 18:22, Oliver Larkin via Faudiostream-devel >> > > <faudiostream-devel@lists.sourceforge.net> a écrit : >> > > >> > > I can't imagine many people are using max4/5 any more - I would >> > > deprecate it to and make faust2max6 become either faust2max or faust2msp >> > > - I >> > > think cycling 74 just call it “max” these days. >> > > >> > > I believe the licence is more prohibitive on faust2faustvst. Also it >> > > has functionality for QT GUIs, which should probably not be part of >> > > something mainly intended for win/osx. I don't think faust2vst should do >> > > user interfaces (I also feel the same about faust2au) >> > > >> > > perhaps the cross compilation scripts could be in a separate folder? >> > > does that only work linux? does it have relevance on other platforms >> > > >> > > faust2pd imo, should just make the object >> > > >> > > the automatic generation of help patches for max/pd binaries is nice >> > > if it works but I've rarely had success with those scripts. I feel it >> > > would >> > > be nice if the faust2xxx just made the binaries >> > > >> > >> - also some kind of global environment variable to enable/disable >> > >> universal binaries on macOS, would be much appreciated ==> what precise >> > >> use-case do you have in mind ? >> > > >> > > I can't currently build with faust2max6, because it is trying to link >> > > libsndfile, which depends on libvorbis, which I've installed via >> > > homebrew, >> > > only in 64-bit. so I have to reinstall everything in homebrew (because >> > > ffmpeg depends on lbvorbis etc.). it's not much fun! I don't necessarily >> > > want 32 -bit max objects, I would prefer not to have to reinstall loads >> > > of >> > > stuff and eat my hard disk space. I feel the tide is turning a bit and >> > > that >> > > 32 bit is being obsoleted (logic/cubase/ ableton) are all going 64 -bit >> > > only. I'm looking forward to not having to build universal stuff any more >> > > >> > > >> > > >> > > >> > > >> > > >> > >> On 27 Oct 2017, at 16:48, Stéphane Letz <l...@grame.fr> wrote: >> > >> >> > >> This is indeed the result of « history » : some scripts are more >> > >> recent or revised versions of older ones. We could possibly deprecate >> > >> some >> > >> of them, and possibly move them in a « unsupported » folder. What I >> > >> can >> > >> say on the examples you gave : >> > >> >> > >> - faust2msp was for Max/MSP 4/5 versions, faust2max6 came later for >> > >> Max/MSP 6/7,: it is OK for Max/MSP users to deprecate faust2msp ? >> > >> >> > >> - faust2vst was developed first; faust2faustvst is Albert more >> > >> complete version. Albert does faust2faustvst compelety supersede >> > >> faust2vst? >> > >> Could faust2vst be marked unsupported ? Could/should faust2faustvst be >> > >> renamed faust2vst ? (for naming consistency purpose…) >> > >> >> > >> - faust2w32xx are cross-complation scripts >> > >> >> > >> - faust2sc / faust2supercollider don’t have exactly the same purpose >> > >> AFAICS ? Any Supercollider guru to comment more ? >> > >> >> > >> - faust2pd/faust2puredata don’t have exactly the same purpose AFAICS >> > >> ? Any PureData guru to comment more ? >> > >> >> > >> - faust2api does not aim to replace them : faust2api is meant to >> > >> produce a Faust/Audio engine with an extended API, that could be >> > >> monophonic >> > >> or polyphonic, which User Interface (or any control interface BTW) will >> > >> be >> > >> developed later on, depending of the applications specific needs. >> > >> faust2api >> > >> aims to give developer more control on what UI they are going to branch >> > >> over >> > >> the generated Faust/Audio engine. >> > >> >> > >> - also some kind of global environment variable to enable/disable >> > >> universal binaries on macOS, would be much appreciated ==> what precise >> > >> use-case do you have in mind ? >> > >> >> > >> Stéphane >> > >> >> > >> >> > >> >> > >>> Le 27 oct. 2017 à 14:05, Oliver Larkin via Faudiostream-devel >> > >>> <faudiostream-devel@lists.sourceforge.net> a écrit : >> > >>> >> > >>> hello all, >> > >>> >> > >>> IMHO there are too many faust2xxx scripts with similar functionality >> > >>> and names, that regularly break >> > >>> >> > >>> faust2msp / faust2max6 / faust2pd / faust2puredata / faust2vst / >> > >>> faust2faustvst / faust2w32* / faust2sc / faust2supercollider >> > >>> >> > >>> is the plan that faust2api replaces this? >> > >>> >> > >>> I think what is included with the distribution should rely as little >> > >>> as possible on third party tools such as macports, and, although the >> > >>> “pure” >> > >>> based scripts are great, it's probably a bit of a big dependency, I >> > >>> think >> > >>> the distribution should include only one script for each target, which >> > >>> should handle building on different platforms and have as few >> > >>> dependencies >> > >>> as possible other than the sdks >> > >>> >> > >>> e.g. faust2vst / faust2pd / faust2max / faust2sc >> > >>> >> > >>> best >> > >>> >> > >>> oli >> > >>> >> > >>> >> > >>> >> > >>> >> > >>> >> > >>> >> > >>> >> > >>> ------------------------------------------------------------------------------ >> > >>> Check out the vibrant tech community on one of the world's most >> > >>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> > >>> _______________________________________________ >> > >>> Faudiostream-devel mailing list >> > >>> Faudiostream-devel@lists.sourceforge.net >> > >>> https://lists.sourceforge.net/lists/listinfo/faudiostream-devel >> > >> >> > > >> > > >> > > >> > > ------------------------------------------------------------------------------ >> > > Check out the vibrant tech community on one of the world's most >> > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> > > _______________________________________________ >> > > Faudiostream-devel mailing list >> > > Faudiostream-devel@lists.sourceforge.net >> > > https://lists.sourceforge.net/lists/listinfo/faudiostream-devel >> > >> > >> > >> > ------------------------------------------------------------------------------ >> > Check out the vibrant tech community on one of the world's most >> > engaging tech sites, Slashdot.org! >> > http://sdm.link/slashdot_______________________________________________ >> > Faudiostream-devel mailing list >> > Faudiostream-devel@lists.sourceforge.net >> > https://lists.sourceforge.net/lists/listinfo/faudiostream-devel >> >> >> >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> _______________________________________________ >> Faudiostream-devel mailing list >> Faudiostream-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/faudiostream-devel > > > > > -- > Dr. Albert Gr"af > Computer Music Research Group, JGU Mainz, Germany > Email: aggr...@gmail.com > WWW: https://plus.google.com/+AlbertGraef > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Faudiostream-devel mailing list > Faudiostream-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/faudiostream-devel > -- Julius O. Smith III <j...@ccrma.stanford.edu> Professor of Music and, by courtesy, Electrical Engineering CCRMA, Stanford University http://ccrma.stanford.edu/~jos/ ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Faudiostream-devel mailing list Faudiostream-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/faudiostream-devel
