On Don, 2017-02-23 at 15:32 +0100, Björn Eriksson wrote:
The Pduino version you did Roman, with less dependencies, was that released the ordinary ways
No.
- and might it even be searchable through Deken? If so... what to
look for?
No. I haven't touched it for quite a while. Back then, when we (Olsen and me) did it, we had two goals in mind:
* make it easier to maintain and to distribute by removing avoidable dependencies. The original [pduino] used some dependencies in a way that made it really hard to use outside of Pd-extended, for instance by using [zexy/makesymbol], which doesn't work with vanilla zexy that ships as multi-object external library.
* create a GUI version that keeps of track of the state of each pin and facilitates experimenting.
We hoped Hans would incorporate our changes, but he refused to. I don't know if someone took over maintenance of the original [pduino]. If it turns out to be orphaned, I'll be happy to make a proper release and take over maintenance. However, I'll continue working on our fork, not on the original pduino. I hope this is the correct process.
It still has two dependencies, [comport] and pdstring from moocow. The latter can probably be avoided, nowadays. I wonder now what the proper way to deal with dependencies is in Deken. Is there some agreed upon declaration of dependencies for Deken packages?
Roman