@oid Valid points. That speaks for keeping the software free.

@plutoro
A journey worth to watch:
https://media.ccc.de/v/lac2018-102-mod_building_a_sustainable_linux_audio_based_business

What is your opinion about using PD for this type of project

I would not use PD for a hardware product like this. Even less if I would start all over again.
The community is small: In the future, the pool of people you could hire would be small.
The documentation could be better.
Even the graphic account is falling a bit short for a patching environment.
And there is a lack of debugging-tools.

While you are struggeling to solve how to get midi-i/o without jitter around the block-boundaries of 64 samples, there are popping up tens of new AI libs in Python.

embedded linux based project, most probably ARM cpu

This might change in the future, as technology moves on

Also resources wise?

PD has overhead, but is running on such a board. You can do very basic multithreading.

Organelle

The reason why someone would buy this, is it's open architecture.

Also related to the quality and diversity of the tools available?

Also related to the protection of the work, is there any solution to make the project "closed" ?

These are two conflicting statements in the PD-world, imho. And once again, having a closed design in mind, I see no reason of using PD instead of more popular languages.

Libraries have different licences. For example [expr] has a different license than PD-vanilla.

Thanks for the input guys, really interesting point of views

Would be interesting to know which specific platforms/languages/toolkits you would prefer instead if you were in our shoes and why?

for example this is a very good argument:

"struggeling to solve how to get midi-i/o without jitter around the block-boundaries of 64 samples, there are popping up tens of new AI libs in Python."

For example [expr] has a different license than PD-vanilla.

It is also BSD now < https://lists.puredata.info/pipermail/pd-list/2019-09/125996.html >.

@plutoro This is still a difficult question to answer for the same reason as stated in my first post, knowing linux, ARM and 16 channels of instruments tells little, we do not know things like what sort of sequencer it is or the capabilities of that sequencer. What can these instruments be? are they 8 bit monophonic samples or 24 bit 128 note polyphony multisamples or granular synths or what? You really need to work out a full spec before sane help can be offered. Your needs may only be met by a more general purpose language like C, or linux and ARM might be massive overkill in both expense and complexity.

The software for the digital audio processing within hardware is written in assembly language specifically for the processor.
The software for the control surface layer is often written in a higher language.
The Organelle is very unusual.
David.

@oid

14 channels of monophonic sequencing, 32 steps with probabilities

2 channels of polyphonic sequencing each with 4 polyphony, 32 steps with probabilities

14 sample based monophonic sound generators at 24/44.1 each with basic adsr envelope and multimode filter and overdrive

2 channels of polyphonic sample based generator with help of synths engines each consist of 3 envelops and 3 lfos, 1 multimode filters, basic sample scan (taking in consideration the granular aspect if is not a cpu hungry process, but I suspect it is)

total of 16 insert effects, one for each channel, send return reverb and delay and a basic master chain effect with multi-band compressor and a limiter.

so a total of max 22 channels polyphony of sample engines at 24/44.1 with a really low buffer size to allow midi sync capabilities in very good stability state.

@oid said:
You really need to work out a full spec before sane help can be offered.