so externals that work with tcl/tk won't work, right?
Yep. And ALL the externals also! I rewrote EVERYTHING. The API is different. The DSP has it own thread. Thus externals must be thread-safe. Moreover Spaghettis aims to allow live-coding. That implies to run DSP at the same time another DSP graph is built! But IMHO the API is not mature. Before to think about externals creation, it would be required to define it more precisely with interested devs. Once done it will not change. Thus it has to be think twice! Also i would like to add much more objects native. But all of that will be able only with stable release (it is still an alpha version < https://en.wiktionary.org/wiki/alpha_version >). There's a lot of work remaining before.
One more step!
That threads could contain few responses:
I don't like big blocks of text (it's hard to translate, hard to read for lazy frenches).
I prefer examples.
Anyway i'll have to redo all of them again once the JUCEd GUI done.
Less things is less work!
Notice that i'll remove a lot of features in next version < https://github.com/Spaghettis/Spaghettis/issues/25 >.
I don"t have time for everything.
Make the DSP foolproof will be the main task.
I will be more than happy in the future to let users improve the help/turorials.
IMHO it is a thing in FLOSS that newcomers can do first....
...before to jump into the source code and help me to tweak the stuff.
That's why there's no already built downlable thing (for now).
I want the users to be motivated to see under the hood.
And to not hijack that thread, probably a good idea is to continue on those above.
where's this by the way?
There: < https://github.com/Spaghettis/Tools >.
But as it is just for my fork, that's not compatible anymore with Pd.
Note that it was a very painfull experience to "clean" the Puckette patches.
For me the official manual of Pd is the Puckette book.
That's why all the tutorials can not be changed easily (i.e. without changing the book also).
IMHO instead to change everything in one shot (that causes a lot of never-ending threads) just try to stick to a pragmatic step-by-step policy. First improve what's depend of Pd-vanilla ownership. The FLOSS manual was a great community documentation, and it should be updated, but that task is out of scope.
Let people maintains their work, maintain yours first.
- Renovate the help / tutorials patches (it took me three monthes for Spaghettis).
- Achieve the Pd translations (i mean the software itself) if not.
- Create GitHub pages for a new fresh documentation (make it translation friendly).
- Link the app to it if required (personnally i don't like html help pages in App, but it seems everybody likes!).
My 2 cents (again).
(((Of course my POV is very GitHub based, and i'm pretty sure it could be also debated!)))
@porres For instance on my fork i put all the tutorials outside of the software repository < https://github.com/Spaghettis >. I created an organization that owns all the stuff. And thus i could give easily the rights for anybody to work on those tutorials, without to care to add noise into the main development. I could even give push rights for an user (that have no idea about C/C++) without fears (for me and him/her/it) to make something wrong. In my case i don't have time to spend in large debates, and such with that approach i would quickly give/split responsabilities to avoid to blow my head. Anyway that is only speculations, since in my case i have zero user, and in your case as you said:
Pd Vanilla is developed and maintained by one person: Miller Puckette.