I think its great if PiSound can be a complete ‘off the shelf’ product that allows end users to utilise a rPI without Linux knowledge. a ‘hardware PD’ box.
In many ways, that’s my goal for the rPI too… (though not necessarily w/ PiSound)
I also understand/respect that you want to have this as a differentiation from other products.
I guess the question is…
Im bringing other open source projects to PiSound, e.g. MEC, but also Orac which contains 30+ modules written by C&G for the Organelle. Mutuable instruments ‘modules’ (clouds, braids, elements, rings etc) , and Ive also been demonstrating Norns on Push2/PiSound.
so I guess I have a bit of an uneasy feeling, if this is all one way …
e.g. if PiSound starts to have ‘exclusive’ patches and apps as a competitive advantage, whilst others are allowing stuff to come to PiSound.
it kind of feels unbalanced.
this is why id have preferred building on Orac, so that these could directly go back into the ‘pool’.
(of course, I could ‘port’ your patches, I believe they are gpl?, to orac, and release… but that feels odd, since you have already done the effort - would it not be better if they were released under your name)
this feels to me like open source, where everyone contributes, and the end users are the winners.
put another way…
I think PiSound is the best music solution for the rPI, in fact arguably the only complete solution (midi + audio in and out). this is because
a) the hardware is very simple, and high quality/efficient.
b) blokas support the software side, rather than chuck a hat at you, and say get on with it.
so for end-users I have recommended it many times.
(did you not notice, I put PiSound up-front in the norns demo… similarly, Orac 1.1, I hope to ‘promote’ on the PI using a PiSound)
really the only alternative is an external usb audio interface, but that’s bulky…
(an organelle/norns is much more expensive)
so I do not think you have to worry being unique in providing a rPI app or even patchers, you’d almost be better just promoting the rPI as a music platform (probably the bigger ‘question’ for most)… and they will naturally come to you for the hardware anyway
( a bit like Steinberg/VSTs… sure they sell a product, but vsts generally made the whole market more viable)
so this is my take, its not really about ‘credit’, its more about having a solution that can enable users to use across platforms (e.g. developing patches on your mac, then chuck it on to a rPI/PiSound) .
of course, I recognise, im not trying make money selling a product so perhaps I have the luxury of having this attitude to open source… so im more voicing this, to see how this might work for blokas.
as for how to present… its a good question, and probably one we will have to address in a few weeks when I release Orac 1.1 - at that point there will need to be a bit of clarity, as its going to raise a few issues.
e.g I suspect Orac is not going to work with your pisound app, and ive no way of testing given I don’t have an android device.
perhaps that doesn’t matter, but I think there might be some that might enjoy Orac given its popularity on the Organelle
also I still think the approach for the single module model is not the right way… as I mentioned before, there is nothing stopping you have a single module with fixed routing in Orac that still follows the same core architecture and yet retains compatibility…
(the router module is not a requirement, like every module it can be switched out, and doesn’t even need to be a module!)
the only thing you would require to do this, is a single option, to deactivate module selection, and even that I think is potentially unwise… e.g. you could still use it to allow you to swap in/out different fx for your ‘synth’.
( I recognise, potentially hardcoding the router/clock is something you might want, as I do understand that is a level of complexity for end-users, and some might prefer a non-modular interface)
the other advantage of this approach, is ive already created videos on how to create modules for orac, so that’s a resource, that patch developers could use.
finally, I guess my main aim here is, is to consolidate, so that we all push in the same direction, we all have limited time, and this is a pretty niche area - so we are unlikely in the short term to have a mass of open source developers rushing to help … so definitely a balancing act of how we both reach our goals.