Hey guys, new to the forum

I represent a group of musicians and programers that wants to start a commercial project related to a groovebox.

We are in the phase of explore the routes we can have to achieve our goals and implement our concept.

What is your opinion about using PD for this type of project, the project is related a lot to complex sequencers, samplers, synthesis and basic audio processing.

Looking forward to your opinions.

Thanks

@whale-av $100 might get you something in the low end Electribe range, but that is pushing it and there does not seem to be a market for low end small manufacture music gear, the big names have that area pretty well tied up, small manufacture is mid range and top of the line. $20k is not much when it is split between 5 or 6 people, which is about the number of people you would need to do such a project in a reasonable amount of time assuming these people enjoy having a life. If that is still too steep there are plenty of ways to trade labor for cost when starting out. Final assembly, installation of thru-hole parts, moving from board mount to panel mount for pots/switches/etc, off the shelf box with custom panels. Some companies have started out with a sort of kit, buyer does final assembly, which generally is just mounting the board, closing up the box and pushing on the knobs, see a fair amount of this in the eurorack world and even Korg has gone down this path. Lots of options.

An aside for touch screens, they dislike wet fingers and that is fairly important to remember here, fine in the studio but not so great on a hot sweaty stage. Products aimed at live performance should have all performance controls as physical controls. This is probably the main reason as to why touch screens have not replaced physical controls and most often serve primarily as a screen which also happens to give easier access to the deeper editing functions.

@plutoro

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

Not really, and making it closed would kill most if not all of the advantages of going the linux/pd route.

@oid said:

Not really, and making it closed would kill most if not all of the advantages of going the linux/pd route.

Pd seems to run on FreeBSD. So it is possible to create a proprietary bundle OS + Pd.

@ingox I meant more in the practical sense, a license is not really going to stop a thief and a small startup is not going to be able to justify legal expense required to force them to stop. Anything you do to make it more difficult to copy will remove some of the ease of the linux/bsd based system and make it more difficult to keep it user extendable. If the user can not easily edit or add patches and you have to go through that extra work to keep things difficult to copy, what is the point of such a system? You are just adding needless overhead and expense. In the end no one is going to bother with stealing the design unless it is unreasonably priced and the market is there, if the market is there it is because you built it, which will go a long ways to protecting your design and by that point you likely are onto a new design. From my view the main advantage of the linux/bsd and pd platform is you get free development from the user base, the more difficult that is the less they will develop new patches for you.

@oid Surely you can modify the Pd source code, compile it and distribute the binary and it would be difficult to reverse engineer it to get the modified source code.

If this route is beneficial to a business model depends on the business model. I for certain support free software, but wouldn't claim that no successful startups that produce proprietary software do exist.

@plutoro didn't even mention that a community would produce patches for the project or help with the development. Most musical hardware out there doesn't provide this possibility...

@ingox One of us is missing something obvious and I am not entirely sure who, but there is no real need to reverse engineer the software, just copy the binaries along with the entire file system to the cheap knockoffs you had produced.

As far as the community developing patches, if you build you project around linux/bsd and pd you are not going to stop the community from doing it, someone will figure out puredata is buried in there and find a way to start changing things. Might as well just work with them from the start, it is free development.

this person made one with raspberry pi

@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.