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
