the idea of signal + peak is … am i getting anything? is it clipping? … after that I suspect a small vu starts becoming less valuable… but perhaps we have more room than that to play with.
(one issue is the smaller it gets, perhaps it will be harder to see if its clipping, but we can see this once we get there)
midi, agreed i think omni… and as mentioned, I think ‘sync/clock’ is different from notes/cc.
however I will say, probably sync could become more general… e.g. Link/Midi Clock are both external sync , and with another icon for ‘internal clock’
pd-opts?
@oweno what did you think of a pd-opts file , as I proposed (a bit off topic ;)) here
… or do you think a more specific approach to libraries, would be better?
(Im think the pd-opts, gives a bit more flexibility, whilst sorting out the library issue too)
curated library?
I agree with @shreeswifty , that a ‘curated’ set of externals for organelle is a great idea. less for patches to distributed, and would give users something to ‘get started with’… as vanilla pd is very limited 
(I dont think versioning is too problematic, since patchers will/should just target what is there, or provide there own versions to override)
I think if we do this, its important that the ‘curated externals’ are properly sourced/credited.
what I mean by this is:
- a repo which contains the source code, with makefiles to build
- details of origin e.g. who was the author, where the source comes from (website), what licence covers it usage
as an open source developer, I think these are important points not to be overlooked, I get frustrated when I come across projects, which use others code but don’t credit it properly - and also you cant track back to where it came from, this can make it very difficult to update later on.
(also not doing this can lead to us potentially breaching licence terms esp. with GPL!)
I don’t think this has to be an onerous task, but has to be done from the outset.