[L2Ork-dev] cyclone merge resolution (Re: updating cyclone)

[Jonathan Wilkes]

> If we eventually make cyclone into a single binary back, as I've pondered it is the way to go for us, would you still like to keep them as separate binaries in purr data?
Yes. For many reasons. Off the top of my head the most important is that dynamically loading a single "cyclone.$extension" binary at startup using the OS's dynamic 
loader API automatically adds all class names and creator names to the object loader list. That unnecessarily pollutes the global namespace at startup.
At the same time, the thousands of patches written in Pd-extended should continue working in Purr Data. To accommodate that, the various 
Pd-extended libraries should be available a la carte, which essentially requires one class per binary. That way a user can find a ten year old patch 
and have a good chance of it working in Purr Data _by_ _default_.
Equally important, a user should be able to [declare] their paths and libs and have those get found before the ones in the global path.
The only way to accommodate both cases is to have one class per binary. (With small exceptions as necessary, like Gem which I mentioned 
on the Purr Data issue tracker.)
-Jonathan

> cheers 


2017-06-19 10:02 GMT-03:00 Jonathan Wilkes <jancsika at yahoo.com>:

> I did the necessary changes tonight to put a beta2 release out, compatible to the purr data release. Objects now can also be created as [cyclone/>~] in vanilla. Help files have also been updated.
Great!
I've got a bugfix release for soundfiler et al to get out, then 
a general memory allocator issue to investigate. Once those are 
done I'll take another shot at merging pd-cyclone.
-Jonathan




   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20170619/ef820284/attachment.html>