keep the good vibes coming

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

@CalBassist @Dizzy-Dizzy There has been [joystick], the [hid] for windows, once upon a time. Not sure if 32 or 64 bit, - I think this was in PD-extended times.

@Polaris said:

speed up the playback of tabread4~.

this you can do by speeding up the [phasor~] driving it.
With [tabread] you can parse an array in the control domain.

I think I may have managed to start the patch up in batch mode. But doing so broke nearly every object, turning them all into boxes with red outlines.

How did you do it? Batch mode should not show any GUI at all.
https://en.wikipedia.org/wiki/Batch_processing
is this what you want?

Which PD version are you using?
In Linux you can use [shell] from ggee lib to start a patch with -batch flag from another patch.
Several instances of PD are running in an asynchronous manner.
And as they can not communicate with [s] [r] or similar, this would require adding an input/output (probably with [soundfiler] / [writesf~]), a [loadbang] routine and a message to quit the instance when done.
All this might not be a good idea, depending on what you want to do?
So this is just guessing ...

Maybe better, you could rewrite 3.audio.examples/G09.pitchshift by replacing ~ objects with their control domain substitute.

As I understand it, one way to accomplish what I'm trying to do

Please, be more specific in what you want to do, what you have been trying and what doesn't work. In detail. And upload a patch.
Sounds like a XY problem.
https://en.wikipedia.org/wiki/XY_problem

Please use the return-key when posting. Structured paragraphs are reader-friendly.

@Polaris said:

What I don't want to do is play through the input array in real time, which means that that the objects and patches included in Puredata that are designed to perform pitch shifts are largely useless to me. They play through the file too slowly.

you could run a customized example patch in -batch mode to get the result asynchronous and "instantly".
https://puredata.info/docs/faq/commandline

I did not look at your patch but as far as I can remember, I had success extending the lower tracking range by up or downsampling the fiddle~ sigmund~ or helmholz~ object. This might work for the upper range, too. Keep filtering aliasing in mind, while up /down sampling.
The instrument's bell-like tones might confuse the tracking. Low pass filtering harmonic content might help.

@deframmentazione-geometrica also see D04.envelope.quartic.

And F09.declickit in the helpfiles for phase-consistency in trade for jitter in the sequence.

clickless-onoff~.pd

EDIT: and D06.envelope.portamento sweeping pitch, not frequency

@Knallberto workaround to find lost posts of the old forum:
do an online search of
' topic's name ' pure data
to find it's new address
https://forum.pdpatchrepo.info/topic/4866/dj-vj-scratching-system

more than pros and cons:

• Seems like a new generation is starting with PD now. A wiki could be another democratic resource.
• There are already many different resources to learn PD, easy to find, online and offline.
• PD has nothing to do with consumerism, imho. This is neither Eurorack nor VST. It is more about ideas than downloading existing tools. PD is a development environment, something like a blank paper. Very individual. Apart from learning the language, there is no right or wrong.
• You can do much more apart from DSP with it. Many users are artists, not musicians. An encyclopedia would never be complete and feels like a strange perspective because science, in the sense of writing down what others did, can not be the very base of art.
  Yes, PD is ideal for designing a kick-drum and although it's purpose is free, PD and many power users are more in the tradition of IRCAM and similar.
• As the PD community is small and methods and techniques aren't PD specific, a wiki on DSP in general with sub-forums and sub-sections or tags in each article for code examples in C, Python, Matlab, PD, Max, SC, VCV ect. could connect many more people and would make more sense imho.
• There is already the big Wikipedia with DSP and software programming, too. Rewriting everything would be pointless. But links to examples in different coding-languages are rare.
• It might make more sense to use a wiki as some kind of meta resource of weblinks.
• For example, your list of reverb techniques is lacking a lot and the introduction is misinformation, as it describes vaguely only one specific way of many in creating a reverb.
  If this would be a wiki page, it would require many more contributions for becoming more useful than an online search. And as others said before, I doubt this is going to happen if PD only.
• Much more important to me would be making a backup of this forum.
  It is an important resource and it would be pity if it would be gone. This happened to many forums for different reasons before and all their information will be gone forever.
  Even a frozen mirror of the current state, saved on some free and independent server would be better than nothing. Even plain .txt and .pd files could help, if it's not trivial to run the forum as a backup.
  It would be much harder to learn PD without this forum. For example, I guess almost everyone trips over the [$0-in_a_message_is_not_working( and such things.