Yes and a topic that I like very much.
We're in 2020! Like I always say, we sent a spacecraft to the moon with a 2.048 MHz computer

@cheesemaster said:

-Ubuntu Studio, maybe an RME PCI card

Why RME PCI, you can find good external soundcard, I guess it depends on the computer that you will choose (more on that later). Yes I like Ubuntu Studio, good choice.

-Really only doing audio (oscillators, arrays, filtering, delays) No graphics.

Perfect, start pd with -rt -nogui
Use [pd~] only if topping 100% CPU (pd is single thread).

-Keeping the the machine quiet (low fan noise) is VERY important.

Fanless is possible, again depending on the computer you choose.

What CPU specs matter most for common audio and MIDI tasks in PD? Number of cores? Thread count? Clock speed?

Clock speed = lowest latency (you can push jack to buffer 64) without xruns. If you are not playing live (for example using ADC) you don't need low latency configuration (I am lucky and not very good at detecting latency, my setup is around 38ms (round-trip). You can detect latency using jack_iodelay.

RAM is important if you want to load samples in PD in advance (avoiding glitches).

NVMe SSD if you can.

If I run other apps (VCV rack, Carla, various Jack plugins) will those processes distribute to the other Cores?

Yes, again Pd is single thread. Others are usually better (GUI on a separated thead for example).

Does Pd benefit from a more powerful GPU card? Or will there be no difference if I use the GPU embedded in the CPU? Is it different if I launch Pd without the gui? (-nogui)

If you don't use Gem you don't need a dedicated GPU card.

Here's some ideas for you, I've been building some setup over the years:

Theremin à crayon:

Using a Surface Pro 3 running Ubuntu Studio with a "old" USB 1.1 sound card. Heavy patch using lots of software : Bitwig, SooperLooper, Guitarix and of course PD. Midi (PD), OSC (Bitwig, SooperLooper). Very quiet but the Surface gets hot (fans are kind of quiet like a good laptop).

Heavybox:
https://www.workinprogress.ca/projects/heavy-box/

Similar setup, a quiet PC using a big heat sink and a overrated power supply so the fan never start. Noctura fan on the side (expensive but quiet). Old soundcard (firewire) but I can do low latency. 8 ins/8 outs.

Biscuit box computer:
https://www.workinprogress.ca/biscuit-box-computer/

Mini-pc not quiet, not very fast in this case a cheap usb soundcard (you know +- 8$ barely better than the embedded one).

Phimatics:

A raspberry pi 2 with wolfson audio card. Using only PD with Alsa, I am getting very good result (low latency) quiest setup. But of course I need to be careful with the CPU.

JAS:

Working on a new project, I found this midi keyboard in the trash / snow. I will put Khadas VIM version 1 (ARM) with a BEHRINGER UCG102 (usb soundcard for guitar). Quiet, no fan can be run on a battery (5V). Will post the project when over.

Lattepanda:
Never worked with it, but looks very powerful. There's a price tag. Maybe for the next project.

Cheers

Thank you @Jona I am trying with the lsit2symbol abstraction.
@whale-av actually Y is stuck to the 15...

I connected a 3D Printer using comport and need to track the position of the extruder.
Directly from Comport I get this info:

comport: X : 0 . 0 0 Y : 0 . 0 0 Z : 0 . 0 0 E : 0 . 0 0 C o u n t X : 0 . 0 0 Y : 0 . 0 0 Z : 0 . 0 0
comport: o k

Trying with your patch I am able to remove spaces (using vl2s and edit):

vl2s: symbol X_:0.0_0_Y:0.0_0_Z:0.0_0_E:0.0_0 C_o_u_n_t X:_ 0.0_0_Y:0.0_0_Z:0.0_0
vl2s: **symbol o_k_

edit: symbol X:0.00Y:0.00Z:0.00E:0.00 Count X: 0.00Y:0.00Z:0.00
edit: symbol ok

Actually I just need the integral number after the axis (X,Y,Z). The second group of axes would be great (current position) but the first group (to go Position) is also OK.

I tried using cylone/nth. But the problem is that the list sometimes is longer so looking for the nth is not a good Idea:

comport: X : 0 . 0 0 Y : 0 . 0 0 Z : 0 . 0 0 E : 0 . 0 0 C o u n t X : 0 . 0 0 Y : 0 . 0 0 Z : 0 . 0 0
comport: X : 10 . 0 0 Y : 0 . 0 0 Z : 0 . 0 0 E : 0 . 0 0 C o u n t X : 10 . 0 0 Y : 0 . 0 0 Z : 0 . 0 0

serialtester.pd

Looking forward for your replies

BlurPD is a framework system to extend Pure Data with the ability to make
digital logic circuits while taking advantage of the DSP capabilities of Pure Data. In order to design and simulate interesting circuits, ASIC chips, DSP processors or entire CPU's, all in Pure Data. It is made from jucy fundamental modules (Lego blocks) that when put together turn Pure Data into a madness of bits ...

Bug Fixes & Notes [v3]

Modules [v3]

• GATES : not,and,nand,or,nor,xor,xnor,cfg,icfg,dna,ro,and3,or3,nand3,nor3,xor3,xnor3
• PLEXERS : 2x1multiplexer,1x2demultiplexer,1x2decoder
• MATH : adder,subtractor,multiplier,divider,comparator,comparator2
• IC : bpd1g8n (integrated 8xNAND gates)
• TOOLS : redled,blueled,greenled,yellowled,magentaled,cyanled,sigv,pininv,gateanalyer
  ledmatrix,controller,adipswitch,vled,hexdisplay,sigbridge,pinanalyzer
• WIRING : pininput,pinoutput,pin0,pin1,dipswitch,idipswitch
• MODULES : the core library for BlurPD built-in modules
• ICMODULES : the core library for "IC" modules
• DSP : btom,sin~,pha~,ipha~,cos~
• DSPTOOLS : scope~

New Stuff [v3]

• Changes to the Help system. Better GUI and integration [v3]

patch download
BlurPDv3-[3-7-2020].zip

BlurPD archive (older versions)
BlurPDv2.9-[3-3-2020].zip
BlurPDv2.8-[3-3-2020].zip
BlurPDv2.7-[3-3-2020].zip
BlurPDv2.6-[3-1-2020].zip
BlurPDv2.5-[2-29-2020].zip
BlurPDv2.4-[2-27-2020].zip
BlurPDv2.3-[2-26-2020].zip
BlurPDv2.2-[2-25-2020].zip

Multibit modules for more complex circuits [v3]

4-bit Boran-Tsung function using a 4-bit ALU (arithmetic logic unit) circuit made with BlurPD [v3]

4-bit Xi'n function using a 4-bit ALU circuit made with BlurPD [v3]

Snapshot of the modules system and help system [v3]

Making generative sounds using new DSP modules [v2.9]

Polymorphic circuit [v2.7]

Application 1 of BlurPD system from [v2.3]

Application 2 of BlurPD system from [v2.3]

Hexadecimal display [v2.3]

The Ancients [v2.2]

Complex analysis using a DIP-switch analyzer [v2.1]

DIPSwitch from [v2.0]

This library overrides Pd's f, i, and binop objects to give them a couple of extra features:

• A creation arg that ends with an exclamation point tells the object to loadbang the result. The loadbang occurs either upon instantiation or when a patch initially opens, depending on which version of Pd you're running.
  Some examples:
  • [ f 5! ] outputs 5 as a loadbang
  • [ - 8! ] sets the 2nd inlet to 8 and outputs -8 as a loadbang, since the calculation would be 0 minus 8.
  • [ + 1 2 ] sets the 1st and 2nd inlets respectively
    • sending a bang to the 1st inlet would output 3
  • [ / 1 4! ] outputs 0.25 as a loadbang

• Binop objects also have the following additional methods:
  • [ f2 $1 ( - sets the 2nd inlet.
  • [ . $1 ( - sets the 2nd inlet and outputs the result of the calculation.

Note: Older versions of Pd don't support the overriding of built-in objects, so for the sake of backward compatibility, the objects have an additional creator method with the general rule being to put a grave accent ( ` ) in front of the object's name (ex: [`f ], [`+ ], [`- ], etc. )

blunt.zip

my "audiolab" abstraction library is now available on deken. You'll need Pd-0.50 or later to run this.
Please report any bugs on github: https://github.com/solipd/AudioLab

here is a picture to draw you in (:

Edit:
list of objects:

Soundfle processing
pp.sfplayer~ ... variable-speed soundfile player
pp.grainer~ ... granular sampler
pp.fft-stretch~ ... pvoc time stretching & pitch shifting

Spatialization
pp.pan~ ... constant power stereo panning
pp.midside~ ... mid-side panning
pp. spat8~ ... 8-channel distance based amplitude panning
pp.doppler~ ... doppler effect, damping & amplitude modulation
pp.dopplerxy~ ... xy doppler effect

Effects
pp.freqshift~ ... ssb frequency shifter
pp.pitchshift~ ... pitch shifter
pp.eqfilter~ ... eq-filter (lowpass, highpass, resonant, bandpass, notch, peaking, lowshelf, highshelf or allpass)
pp.vcfilter~ ... signal controlled filter (lowpass, highpass, resonant)
pp.clop~ ... experimental comb-lop-filter
pp.ladder~ ... moogish filter
pp.dynamics~ ... compressor / expander
pp.env~ ... simple envelope follower
pp.graindelay~ ... granular delay
pp.rev~ ... fdn-reverberator based on rev3~
pp.twisted-delays~ ... multipurpose twisted delay-thing
pp.shepphaser~ ... shepard tone-like phaser effect
pp.echo~ ... "analog" delay

Spectral processing
pp.fft-block~ ... audio block delay
pp.fft-split~ ... spectral splitter
pp.fft-gate~ ... spectral gate
pp.fft-pitchshift~ ... pvoc based pitchshifter
pp.fft-timbre~ ... spectral bin-reordering
pp.fft-partconv~ ... partitioned low latency convolution
pp.fft-freeze~ ... spectral freezer

Misc.
pp.in~ .... mic. input
pp.out~ ... stereo output & soundfile recorder
pp.out-8~ ... 8 channel output & soundfile recorder
pp.sdel~ ... samplewise delay
pp.lfnoise~ ... low frequency noise generator
pp.spectrum~ ... spectrum analyser
pp.xycurve

Giải đáp: Cửa gỗ công nghiệp loại nào tốt?

Cửa gỗ công nghiệp đang là sản phẩm được sử dụng thịnh hành trong nhiều năm trở lại đây bởi tính thẩm mỹ cao cùng với chất lượng cải tiến vượt trội. Và để đáp ứng được nhu cầu sử dụng lớn thì có rất nhiều loại cửa gỗ công nghiệp ra đời khiến người tiêu dùng cảm thấy phân vân và bối rối lựa chọn mẫu sản phẩm nào có chất lượng tốt nhất. Vậy bạn nhất định không thể bỏ lỡ những thông tin dưới đây để có câu trả lời cho “Cửa gỗ công nghiệp loại nào tốt?”.

Nên chọn cửa gỗ công nghiệp loại nào?

Để có thể biết được cửa gỗ công nghiệp loại nào tốt, bạn hãy tham khảo Top những sản phẩm được chúng tôi khảo sát và tổng hợp qua những lời review của khách hàng sử dụng trước đó.

Cửa gỗ công nghiệp Composite

Nằm trong Top đầu những mẫu cửa gỗ công nghiệp có chất lượng tốt chúng ta không thể không nhắc đến dòng cửa gỗ nhựa composite. Loại cửa này có tính ổn định tương đối cao và có ưu điểm đặc biệt là khả năng chống nước hoàn hảo. Và một trong những yếu tố làm nên điều đó là nó có cấu tạo bao gồm các hạt PVC kết hợp các chất phụ gia cao cấp trong quá trình sản xuất giúp sản phẩm không bị cong vênh, co ngót hay mối mọt. Điều này rất phù hợp với khí hậu nhiệt đới gió mùa tại Việt Nam.
Ngoài ra, cánh cửa gỗ công nghiệp Composite có trọng lượng vừa phải cũng như được trang bị gioăng cao su giúp việc đóng mở diễn ra êm ái và không xảy ra tình trạng xệ cánh. Không những vậy, cửa gỗ Composite còn có khả năng cách âm và cách nhiệt tốt do cấu tạo từ những thành phần đặc biệt và được đúc khuôn nguyên tấm với các mối nối có độ khít nhất định. Để xem thông tin chi tiết, các bạn có thể truy cập website https://sundoor.vn/ nhé!

Cửa gỗ công nghiệp MDF

Nếu bạn tìm một mẫu cửa gỗ công nghiệp tốt thì không thể bỏ qua dòng MDF. Đây là loại cửa có giá thành rẻ nhưng vẫn đáp ứng nhu cầu sử dụng cơ bản cho khách hàng cũng như tiết kiệm được chi phí đáng kể. Điểm mạnh ở dòng sản phẩm này đó chính là khả năng chống cong vênh và co ngót trong mọi loại thời tiết. Ngoài ra, cửa gỗ công nghiệp MDF được làm bằng chất liệu gỗ ép, do vậy mà dễ bị mục chính vì thế mà đây là sản phẩm có khả năng kháng nước kém cũng như chịu ẩm ở mức độ thấp. Chính vì thế mà cửa gỗ công nghiệp MDF chỉ phù hợp lắp ở nơi khô ráo như phòng ngủ để có thể nâng cao được tuổi thọ cho sản phẩm. Nếu bạn muốn cửa có thời gian sử dụng lâu thì nên tránh lắp đặt ở những nơi tiếp xúc với nước thường xuyên. Hơn nữa với khí hậu nóng ẩm như ở Việt Nam thì khách hàng nên cân nhắc trước khi lắp loại cửa này.

Cửa gỗ công nghiệp HDF

Cửa gỗ công nghiệp HDF cũng là sản phẩm được nhiều khách hàng lựa chọn sử dụng trong thời gian vừa qua. Sản phẩm được sản xuất từ gỗ công nghiệp HDF ép nhiều lớp bột gỗ với keo và chất phụ gia. Điều này giúp cửa có khả năng chống ẩm tốt nhất. Bên trong cửa gỗ công nghiệp HDF được sử dụng tấm ván HDF màu xanh có khả năng chống ẩm và bảo vệ cửa tốt hơn khi thời tiết nồm. Nhưng để cửa có độ bền lâu thì tốt nhất là khách hàng nên tránh cho tiếp xúc với nước. Cửa gỗ công nghiệp HDF có đặc điểm nổi bật là không bị cong vênh hay co ngót dưới tác động của môi trường hay thời tiết.

Cửa gỗ công nghiệp ghép thanh

Một trong những loại cửa gỗ công nghiệp mà khách hàng có thể tham khảo đó chính là cửa gỗ ghép thanh. Sản phẩm này có bản chất là gỗ tự nhiên sau khi được xử lý thành từng tấm nhỏ và ghép lại thành cánh cửa. Và để hoàn thiện sản phẩm, nhà sản xuất đã phủ lên một lớp MDF hoặc HDF cùng với lớp sơn bóng. Về cơ bản thì loại cửa này vẫn mang bản chất cửa gỗ tự nhiên nên dễ bị cong vênh, co ngót theo thời gian sử dụng. Hơn nữa, cửa có trọng lượng nặng tương đối và có thể xảy ra tình trạng xệ cánh. Chính vì thế nếu khách hàng muốn sử dụng một loại cửa được làm từ gỗ tự nhiên nhưng sản xuất theo phương thức công nghiệp thì nên xem xét cẩn thận trước khi mua.

Chắc hẳn với những thông tin mà chúng tôi đã tổng hợp và chia sẻ thì bạn cũng đã biết được cửa gỗ công nghiệp loại nào tốt và lựa chọn cho không gian nhà mình sản phẩm phù hợp. Nói chung cửa gỗ công nghiệp tốt hay không sẽ phụ thuộc vào mục đích sử dụng trong từng không gian nhà bạn. Chính vì thế mà bạn hãy xác định lắp cửa ở đâu để đưa ra quyết định đúng đắn và phù hợp nhé!
Và đừng quên ghé thăm website sundoor để tham khảo những mẫu cửa gỗ nhựa composite hot nhất hiện nay và được đội ngũ nhân viên tư vấn những sản phẩm chất lượng nhất.

@zxcvbs Hi, yes I realise the patch is very counterintuitive, I'll do my best to try and explain what's going on. Let's forget about polyphony and consider one voice.
The PMops abstraction is the single voice, inside it are the three operators (PMop, both badly named sorry) and the tables subpatch. The basic structure of each operator could be reduced to the simple:

but the +~ object, instead of receiving the phase from a fixed modulator, it receives it from a table. Each operator has its own table, so operator 1 receives the phase from tabreceive~ $0-phase1 which is connected to +~.
At the same time (to populate those tables), the output from cos~ of each operator is sent to all tables, how much of the signal goes to each is decided in the modulation matrix.
The reason I decided for this arrangement is because this way each operator can send its phase to any operator, including itself (feedback). As explained in the first post, feedback has to be done with the operator working at block~ 1 in order to sound good, but if an operator receives the feedback every sample (block~ 1) but to that you add the phase of the other modulators every 64 samples (the default block size), the result sounds bad. This is the reason I used this mess of tables, to have an FM-8 style modulation matrix.
If you want to implement hard-coded algorithms, the same thing can be done without tables, patching each algorithm in its own abstraction or subpatch and switch between them as @whale-av suggested in your thread. Plus I see none of your algorithms have feedback, so they don't even need to run at block~ 1, and therefore the approach with tables is really not necessary.
Hope this clarifies things a bit.

Kraken a low-cpu, compact, highly versatile guitar effects stompbox

Intent:

Make a guitar effects rack that would

1. do a lot (includes 8000 pedal combinations)
2. cost very little cpu; and
3. eliminate the need to "connect" effects abstractions

(Master-Kraken-help.pd is the main patch.)

Kraken.zip

The Stack (in this order):

eq3
pre (gain)
3 effect/pedal slots (with clean-dirty "bypass" toggle for the whole set)
with each slot containing
a (tof) menu to select from 21 effects (0 being raw)
3 parameters (mknobs)
a dry-wet slider
a bypass toggle (for that line which crossfades in and out (set by the crossfade control, in ms)
and
an infinite sustain toggle (for that line)
reverb (with brightness and roomsize control and off|on toggle)
compressor (with threshold, limit, ratio, attack, release (zexy~))
master out level.

Kraken also includes:

a simple recorder (record and play (loop) toggles and recording the entire result)
a popup (standard tuning) guitar tuner
an [ adc~ | sample ] (a|s) switch (to test the sound or even post-process a track/file using openpanel)
and
a presets control which loads or saves the current settings (for the entire rack and includes a date+time prefix as well as an entered name for each preset).

Additional Info:

OpenSoundControl (OSC) has been exposed for a future/additional post ("Kraken-OSC") which I have almost finished in Mobmuplat (only, for now, PdParty and others to be added later) and can be accessed via the send and receive to network abstractions inside the patch.
**
EFFECTS LIST:
00-raw
01-chorus
02-compressor
03-delay(3-tap)
04-delay(fb)
05-delay(spectr)
06-distortion
07-filter
08-flanger
09-fuzz
10-looper(fw-bw) (>0.5 on, <0.5 off to record, play forward, or play backward)
11-octave_harmonizer
12-overdrive
13-phaser
14-pitchshifter
15-reverb
16-step-vibrato
17-tremolo
18-vcf
19-vibrato
20-wah-wah

Dependencies:
(which I believe are all available in Deken)
zexy
cyclone
moonlib
iemlib
ggee
plus zexy~ "load on startup"

Credits/Thanks/Acknowledgements:

As I think with most pure data patches Kraken is built on the back of lots of other people's hardwork and diligent effort. In particular, it owes its effects to predominantly the DYI2 library (by Hardoff), the Stamp Album library (by Balwyn), those on the Guitar Extended website (by Pierre), and less so to a few others. And to all of them, I am deeply thankful.

Tally-Ho! Happy playing.

I am very thankful to finally "Release the Kraken!". I hope it may bring you many hours of pleasure, entertainment, and possibly education.

p.s. if you see some of your work inside this, DO please let me know and I will credit you more specifically.

Thanks again. Feel free to ask any questions you may like regarding using the tool, the abstractions, etc., and I will respond to them as soon as I am able. -Peace

Hi everyone. I have frequently revised designs for polyphonic envelopes. i've often misunderstood things about vline~ and scheduling voices in such a way to avoid unwanted clicks while also keeping things on time and snappy.

i'd be really happy to know what your methods are for envelopes.

i submit this patch, a reflection on envelope practices and how i address certain challenges. envwork.pd

this patch makes these assertions:

1- because vline~ maintains sample accuracy by scheduling events for the next block, you can switch dsp on in a subpatch with block~ while sending a message to vline~ and the dsp will be active by the start of the vline~ output. This also works if you need to configure a non-signal inlet before triggering a voice. send a message to such an inlet concurrently with a vline~ message and the parameters will update on the block boundary before the vline~ plays.

2- accounting for note stealing can cause issues in a polyphonic patch. if the stealing note has a slow attack and the envelope of the stolen note is not closed, there will be a click as the pitch of the new note jumps. the voices in my patch apply slight portamento to smooth out this click. if, however, the attack time of the stealing note is faster than this slight portamento it is counterproductive and will soften the attack of stolen notes. Stolen notes need every bit of snap they can get because the envelopes may be starting at a non-zero value. so i limit the time of the portamento to the attack time.

3- to make sure a note that is still in its release phase is treated as a stolen note, it is necessary to monitor the state of the envelopes like so:

switching the dsp off too close to the end of the release causes clicks. after testing, my system liked a full 50ms of extra delay after the end of a release before it was safe to switch off dsp. I don't think this is attributable just to the scheduling delay of vline~ but it's a small mystery to me. possibly there's a problem with my voices.

This all gets a little more complex when there are multiple envelopes per voice. The release time that affects the final output of the voice must reset all envelopes to when it is finished and before dsp is switched off. Otherwise an envelope with a long release affecting something like filter frequency can be held at a non-zero value when dsp is switched off and spoil the starting state of the vline~ on a new note.

finally, on vline~ and sample accuracy and timing, let me type out what i believe is the case. i could be wrong about this. if you programmed a synth using line~ for the envelopes, it would be faster than vline~ but not all notes equally faster. all notes would sound at the block boundary. Notes arriving shortly after the last block boundary might take 90% of the block period to sound. notes arriving just before the block boundary might take 10% of the period to sound.

vline~ will always be delayed by 100% of the block boundary. but the events will be scheduled sample-accurately, so the vline~ will trigger at exactly the real time intervals of the input. a synth with line~ envelopes will trigger any two events within a single block at the same time.

this should mean that vline~ envelopes can be accurately delay compensated and stay absolutely true to input timing, in the case of something like a Camomile plugin.

however, if one was to build a synth for something like a raspberry pi that will act as hardware, would it be better to use line~ envelopes and gain a little bit of speed? is the restriction of locking envelopes to block boundaries perceptible under normal playing conditions?! i could test some midi input and see if the notes in a chord ever achieve a timing spread greater than the block period anyway...

Similar to [pack ] and [unpack ] but instead of the default atom type being a float, the default type is anything.

Also comes with a new creation arg 'a' for anything. Numbers and unrecognized types will also default to anything.

For strict type checking, use f(loat), s(ymbol), and p(ointer).
The pak object will also store unrecognized types as symbols and interpret 'b' as a 'bang' symbol.

You can send lists to any of the additional pak inlets and it will store the list values with the inlet as the starting point. For example, sending the message [foo bar 3 baz( to the 2nd inlet of [pak 1 2 3 4] would result in the list: 1 foo bar 3

The example includes another object called [x ], which is a kind of trigger object that dehusks lists that consist of only 1 element when you use 'a' or nothing for creation args. For pd-vanilla users, the example also requires zexy's [demux].

You can also use "." to skip inlets and assign only specific ones.
For example, sending the message [. . 123( would assign 123 to the 3rd inlet and leave the first two values the same as they were. You can send these messages to any inlet.
The skip arg feature only applies to list and anything type messages, so if you really want to, you can still assign a single period to an inlet by sending it as a symbol.

There are two more objects [@pak] / [@unpak] - reverse pak/unpak, which output the lists in reverse order.

Strict-type error messages are muted by default and to unmute them, you need to send [mute 0( to the 1st inlet. The number sent to mute acts as a bit mask for the inlets, so when a bit is turned on, the associated inlet will output error messages.

pak-unpak.zip