Comments (7)
DBraun
commented on July 18, 2024
1
On the other hand, if you can't break things then you end up with too many things. The purpose of a good library versioning system would be to inform people that there are non-backwards-compatible breaks. People should be able to continue to access the older version if they opt into it.
from faustlibraries.
sletz
commented on July 18, 2024
- since Rust and Julia have a similar embeddable library model this would help to understand what happen in Julia
- we have some ideas on a more modern way to deal with libraries, see: https://github.com/grame-cncm/faustideas#packaging-system-for-faust-libraries. We can possibly enrich this description there with some of your comments ?
from faustlibraries.
magnetophon
commented on July 18, 2024
That looks great!
I don't think my comments would improve it, since you already mentioned Cargo as an inspiration.
from faustlibraries.
josmithiii
commented on July 18, 2024
Hi Bart,
I am very firmly in the camp that preserves backward compatibility
forever. Names are cheap. :-)
The library version can effectively be part of the name, as you and Rust
suggest, but I prefer to be more explicit and either come up with a new
name or create a new collection with its own mandatory prefix.
In general, I think the Faust Libraries should be considered a massive repo
of fodder supporting more specialized and curated downstream collections.
The "standard Faust function" collection is one good example. I personally
mostly use the "original JOS collection" which essentially has the prefix
"old" right now :-). The "compressor overload" situation is a good example
of a group that would be hard-pressed to look coherently organized. The
oscillators are similarly scattered, and how about all those reverbs and
physical models? No one person is going to pull all that together, but
someone might define a preferred subset that they would be willing to
document and curate.
In summary, I would not want to discourage more variations and extensions
in the Faust Libraries, but I also can't imagine documenting everything
that's already there in a unified way, much less what all is hopefully to
come. I think of it as a boiling pot of research ideas and contributions
from which polished products can emerge.
Cheers,
Julius
…On Thu, May 11, 2023 at 7:03 AM Bart Brouns ***@***.***> wrote:
Closed #157 <#157> as
completed.
—
Reply to this email directly, view it on GitHub
<#157 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAQZKFNIVF4BK5LIX4FMYXTXFTWT3ANCNFSM6AAAAAAX6DMDSI>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***
com>
--
Julius O. Smith III ***@***.***>
Professor Emeritus of Music and by courtesy Electrical Engineering
CCRMA, Stanford University
http://ccrma.stanford.edu/~jos/
from faustlibraries.
magnetophon
commented on July 18, 2024
Hi Julius,
I agree backwards compatibility is very important, that's why I brought this up.
I was just thinking aloud on how to best achieve it.
I can see the advantage of making a new name any time a breaking change is introduced.
On the other hand: sure, names are cheap, but if you can't find what you need, you might as well not have it.
There's a fine and subjective balance there:
I think it makes sense to have lot's of ways to generate a sine wave, since each has it's own advantages and disadvantages.
I don't hink it is a good user experience to have tons of legacy functions cluttering things up.
So far it's not too bad, but eventually there will be more legacy code than current code.
Cheers,
Bart.
from faustlibraries.
josmithiii
commented on July 18, 2024
Ok, but how do you then blend functions across a variety of library
versions?
Maybe something like this is what I want:
fi = library("filters.lib");
fi02 = library("02/filters.lib");
os = library("oscillators.lib");
os03 = library("03/oscillators.lib");
process = os.someOsc, os03.someV3Osc : fi.someFilter, fi02.someV2Filter;
Etc.
Then of course the bloat is that the distribution would include complete
copies of older versions of each library
(I measure about 1.7M for all the currently installed libraries, so that's
not a deal-breaker for me, and readable patch-files could be used in ./01,
./02, etc.).
This is easy enough to do individually that I don't mind doing it myself.
My opinion now is therefore to simply maintain a very complete
<FaustLibraries>/BREAKING-CHANGES.txt file, like the JUCE distribution has.
We can then read it carefully before upgrading.
However, this is tricky because Faust decides which Faust Libraries version
to use in its submodule,
so I have to carefully choose when to upgrade both Faust and Faust
Libraries together.
This is unfortunate because the Faust compiler almost never introduces a
breaking change,
so I have been very happy upgrading to the latest master-dev routinely
without getting bit.
I am not worried about API bloat from the creation of new names, because
that's already out of control to the point that I think a new set of small,
focused, downstream libraries is needed. Those can use new names, or reuse
old names incompatibly, but all are protected by newly named namespace
environments. I see the current libraries as an anything-goes pile of
carefully tested proposals for consideration from many authors who don't
have time to fully internalize all relevant pre-existing contributions
first.
Cheers,
Julius
…On Thu, May 11, 2023 at 3:27 PM David Braun ***@***.***> wrote:
On the other hand, if you can't break things then you end up with too many
things. The purpose of a good library versioning system would be to inform
people that there are non-backwards-compatible breaks. People should be
able to continue to access the older version if they opt into it.
—
Reply to this email directly, view it on GitHub
<#157 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAQZKFPN4RAKPZ4O2453FTLXFVRVPANCNFSM6AAAAAAX6DMDSI>
.
You are receiving this because you commented.Message ID:
***@***.***>
--
Julius O. Smith III ***@***.***>
Professor Emeritus of Music and by courtesy Electrical Engineering
CCRMA, Stanford University
http://ccrma.stanford.edu/~jos/
from faustlibraries.
magnetophon
commented on July 18, 2024
I am not worried about API bloat from the creation of new names, because that's already out of control to the point that I think a new set of small, focused, downstream libraries is needed.
What you call "a set of focused libraries" is at the core of what I'm talking about.
As far as I'm concerned, they do not need to be small, as long as they are well organized.
Part of that organization should be in terms of functionality and part of it should be in terms of time/version.
As far as I can tell, that is also what the faustideas link is talking about.
from faustlibraries.
Related Issues (20)
- Feature request: allow si.bus(0) HOT 1
- Error in moogLadder filter algorithm HOT 7
- Add links to source code from libraries docs pages HOT 2
- co.RMS_compression_gain_mono causes core dump HOT 4
- Deprecated examples documentation ?
- N dimensional tabulate HOT 23
- Can the enable primitive become a fully supported feature? HOT 1
- DX7 Library is incomplete
- compilation of Max 8 externals for Apple ARM64 -> ok HOT 1
- Naming conventions for amplitude analysis functions HOT 18
- Strange behaviour of ba.if with fractional conditions < 1. HOT 1
- add edge detection to signal library HOT 1
- I want to help HOT 1
- oscillators.lib : 488 : ERROR : syntax error, unexpected IDENT HOT 6
- invalid links in inline documentation HOT 2
- hoa encoder3D HOT 4
- typo "quantizer.lib" in stdfaust.lib HOT 1
- Make the behaviour of si.smoo SR-independent. HOT 3
- pm.flute_ui_MIDI is not in tune
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from faustlibraries.