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.

@ddw_music

• Is [fexpr~] the best way to check for the phasor reset?

I did it in the same way, or with Cyclone.
@jameslo said:

I think you and I were posting on another topic when @alexandros suggested using [rzero_rev~ 0] to get the previous sample.

cool

• The [rpole~ 1] is essentially a phasor with a signal-rate reset (as opposed to [phasor~], which can be reset, but only with control messages). Is there a better way?

There are [vphasor~], [vphasor2~] and [vsamphold~] from @Maelstorm . I did not try them yet.
https://forum.pdpatchrepo.info/topic/10192/vphasor-and-vphasor2-subsample-accurate-phasors/

Patched my own [vphasor~] with [fexpr~], too and another one with a [pd subpatched] [block~ 1] and [tabwrite~] and another [pd sub] [block~ 1] [tabreceive~] and a feedback-loop, that is basicly forming a ramp by adding itself up.
Both might be expensive? I did not compare their CPU load yet.
Your [rpole~ 1] is neat.

Why not in vanilla?

I am wondering about this, too. Am working on sampleaccurate "audio-control" and slowly making progress.

In your patch [rpole~ 1] is working with a signal-inlet, isn't it?
Or what is it that you tried to say?
Of course you can deform the ramp with [*~] [+~] [samplerate~] ect.

Which is that other forum you mentioned? I am keen to learn more about DSP techniques.

(Tbh I'm a little bit proud of this one )

yeay!

It depends on the method and complexity of synthesis - if you use filters, feedback and anti-aliasing filters ect.
The sampler might basicly be arrays as look-up tables < read interpolated with tabread4~ with a phasor~ < modulated with ramps and some AM.
With similar ingredients you can already patch a very basic synth but more complexity will require some more cpu.
If you want time-stretching and independent pitch-modulation, the sampler will become more complex with FFT.
(You see, in reality either one becomes a hybrid quickly: for example [cos~] is a table-lookup, too.)
Reading a complex pre-made sample will use the same CPU as a very basic sound.
A sampler will require more RAM, as the arrays are stored in memory. You can easily calculate the reqired space for this if you know samplelength, bits and samplerate.
Given the synth- or sampler-apps available for phones, I guess you can patch quite complex instruments in either way. Of course this depends on other expensive tasks running along with it.
The CPU-load depends on blocksize and latency, too.
Often in PD-Vanilla the bottleneck are the GUI elements, wich you might not use anyway.

@jameslo The bug is the delaylines~ not having 1 sample delay.
I am not entirely sure why, but you read them at 0ms, - arguments are in ms not samples and there is the importance of the execution order with delays~, and s~ r~, you can read about in audio.examples/G05.execution.order.pd
But this would lead to a DSP-loop here.

However, I use tabsend~ tabreceive~ and 1 sample arrays, as this is how to do feedback-loops with 1 sample delay.
I created the sending subpatches first, the receiving ones afterwards, - not sure if this is important for the execution order in this case, too?
biquad-resonator-debug_2c.pd

@pharaoh-sean
help > find externals
And please read how to deal with externals in the manual: help > manual > chapter 4 externals
To be sure, delete the zexy folder in /extra before reinstalling it with Deken

(Also, I'd recommend to download the latest version of PD Vanilla from here https://puredata.info/downloads
or there http://msp.ucsd.edu/software.html
instead of using possibly outdated repositories (i.e. Synaptics). But this is unrelated to your question. )

@RetroMaximus mapping might help
map.pd
map-help.pd

@pharaoh-sean After installing Zexy via Deken,

try adding zexy to File > Preferences > Libraries

or add
[declare -lib zexy]
beforehand
[demux]
in your patch.

In File > Preferences > Searchpaths should be PD's /extra folder, and the library should be inside of that folder, of course.

similiar thread here:
https://forum.pdpatchrepo.info/topic/12786/iemlib-in-vanilla-deken-compiling/11

@adammccaffrey you can find the error message in the sources:
https://github.com/pure-data/pure-data/blob/master/src/m_memory.c

the patch is resizing the cloned arrays
here it uses >4Gb of ram

operating system? 32 / 64 bit?
PD-version? 32 /64 bit?

@adammccaffrey probably running out of memory.
How much Random Access Memory does your machine have?

@cfry No, the quote posted by @ddw_music is related to PD's scheduler and the basic difference between update-rates of control versus signal~objects.
You can read about it in PD's manual chapter "scheduling" in the help-menu.

[noise~] has to calculate 44100 random numbers per second, whether you do anything with those numbers or not. [random] just runs when you ask it to.

... and you can poll it every 64 samples only.
That is why

There's one case where you might use [noise~] and [samphold~] -- if the random step function is needed in the signal domain and you expect the sample/hold unit to update in the middle of an audio processing block.

and why [noise~] with the output of [snapshot~] has no advantage over [random].

When I did a comparison test with just one of each (set to fast rate), the cpu load did not differ much

You will only feel the difference in huge patches with many [clone]s and or upsampling in the sum with many other things running.

I am modifying an polyphonic FM synth, which has cloned objects with [phasor~] inside.

Is the random generated inside of the [clone]?
If not, something else might cause high CPU-load.

The cheapest way to get random might not be calculating it in realtime, but reading preset random numbers from a text- or wavefile or an array with phasor~ or [f][+ 1]. But then the random set will loop.

@whale-av @jameslo
now [declare -lib iemlib] made it with 1.22 from Deken on Win10
sorry for the false alarm! and thank you *