Just Another (Drum) Sequencer...SortOf, codename: Virgo

virgo.zip

REQUIRES: zexy, moonlib, tof (as of Pd 0.50.2, all of which are in deken) and hcs (which comes by default with Pd 0.50.2 and is in deken (for extended))

Special Features

• Unique playhead per row; each with their own metro (beat)
• Up to 8 Volume states-per-beat (by clicking multiple times on the bang; where an rms=1 is divide among the states (2 states:0=rms=0(black), 1=rms=1(red); 3 states:rms=[0|0.5|1])
• Design approach: using creation arguments to alias abstractions, so subsequently they are referred to by their creation arguments, ex. in [KITS sample] sample is referred to as [$1]; which is how they are listed below)

(notes: what I learned experimenting with this design approach, I will share as a separate post. Currently, it does not include cut-copy-paste (of regions of the pattern)). I good way to start trying it out is clicking the "R" to get a random kit and a random pattern).

virgo:[virgo/PROJECT KITS PATTERNS]

• PROJECT[KITS PATTERNS]
  • $1:[KITS sample]
    • GUI
      • K: openpanel to load a previously saved *.txt (text object) kit of samples; on loadbang the default.txt kit is loaded
      • S: save the current set of samples to the most recently opened *.txt (kit) preset
      • SA: saveas a *.txt of the current set of samples
      • D: foldererpanel a sample directory to load the first (alphabetically) 16 samples into the 16 slots
      • RD: load a random kit from the [text samples] object where the samples where previously loaded via the "SAMPLES" bang on the right
      • U: undo; return to the previously opened or saved *.txt kit, so not the previously randomized
      • MASTER: master gain
      • (recorder~: of the total audio~ out)
        • record
        • ||: pause; either recording or play;
        • play: output is combined with the sequencer output just before MASTER out to [dac~]
      • SAMPLES: folderpanel to load a (recursive) directory of samples for generating random kits
    • ABSTRACTIONS
      • $1: sample
        • bang: openpanel to locate and load a sample for a track
        • canvas: filename of the opened sample; filenames are indexed in alignment with track indices in the PATTERNS section
  • $2:[PATTERNS row]
    • GUI
      • P: openpanel to load a previously saved *.txt (pattern) preset file; on loadbang the default.txt pattern is loaded; the preset file includes the beat, pattern, and effect settings for the row
      • S: save the current pattern to the most recently opened pattern .txt
      • SA: save as (self-explanatory)
      • states: the number of possible states [2..8] of each beat;
      • %: weight; chance of a beat being randomized; not chance of what it will result in; ex. 100% implies all beats are randomized ; random beats result in a value)gain) between 1 and states-1
      • PLAY(reset): play the pattern from "start" or on stop reset all playheads to start
      • start: which beat to start the playheads on
      • length: how many beats to play [+/-32]; if negative the playheads will play in reverse/from right to left
      • bpm: beats-per-minute
      • rate: to change the rate of play (ie metro times) by the listed factor for all playheads
      • R: randomize the total pattern (incl period and beats, but not the effect settings; beats of 1/32 are not included in the possibilities)
      • CL: clear, set all beats to "0", i.e. off
      • U: undo random; return to the previously opened or saved preset, ie. not the previous random one
      • M: mute all tracks; the playheads continue moving but audio does not come out of any track
      • ||:pause all playheads; play will resume from that location when un-paused
      • per: period; if 0=randomizes the period, >0 sets the period to be used for all beats
      • Edit Mode
        • Check the [E] to enter edit mode (to cut, copy, or paste selected regions of the pattern)
          • Entering edit mode will pause the playing of the pattern
          • Play, if doing so beforehand, will resume on leavng edit mode
          • The top-left most beat of the pattern grid will be selected when first entering edit mode
        • Single-click a beat to select the top-left corner of the region you wish to cut or copy
        • Double-click a beat to select the bottom-right corner
          • You may not double-click a beat "less than" the single-clicked (top-left) beat and vice-versa
        • Click [CL] to clear your selection (i.e. start over)
        • The selected region will turn to dark colors
        • If only one beat is selected it will be the only one darkened
        • Click the operation (bang) you wish to perform, either cut [CU] or copy [CP]
          • Then, hold down the CTRL key and click the top-left corner of where you want to paste the region
          • The clicked cell will turn white
          • And click [P] to paste the region
        • Cut and copied regions may both be pasted multiple times
          • The difference being, cutting sets the values (gains) for the originating region to "0"
        • Click [UN] to undo either the cut, copy, or paste operation
          • Undoing cut will return the gains from 0s to their original value
      • (effect settings applied to all tracks)
        • co: vcf-cutoff
        • Q: vcf-q
        • del: delay-time
        • fb: delay-feedback
        • dist: distortion
        • reverb
        • gn: gain
    • ABSTRACTIONS
      • $1: [row (idx) b8] (()=a property not an abstraction)
        • GUI
          • (index): aligns with the track number in the KITS section
          • R: randomize the row; same as above, but for the row
          • C: clear the row, i.e. set all beats to 0
          • U: undo the randomize; return to the originally opened one, ie. not the previous random one
          • M: mute the row, so no audio plays, but the playhead continues to play
          • S: solo the row
          • (beat): unit of the beat(period); implying metro length (as calculated with the various other parameters);1/32,1/16,1/8, etc.
          • (pattern): the pattern for the row; single-click on a beat from 0 to 8 times to increment the gain of that beat as a fraction of 1 rms, where resulting rms=value/states; black is rms=0; if all beats for a row =0 (are black) then the switch for that track is turned off; double-click it to decrement it
          • (effects-per-row): same as above, but per-row, ex. first column is vcf-cutoff, second is vcf-q, etc.
        • ABSTRACTIONS
          • $1: b8 (properties:row column)
            • 8-state bang: black, red, orange, yellow, green, light-blue, blue, purple; representing a fraction of rms(gain) for the beat

Credits: The included drum samples are from: https://www.musicradar.com/news/sampleradar-494-free-essential-drum-kit-samples

p.s. Though I began working on cut-copy-paste, it began to pose a Huge challenge, so backed off, in order to query the community as to 1) its utility in the current state (w/o that) and 2) just how important including it really is.

p.p.s. Please, report any inconsistencies (between the instructions as listed and what it does) and/or bugs you may find, and I will try to get an update posted as soon as enough of those have collect.

Love and Peace through sharing,
Scott

Thanks guys for the tips and links I will look into that in order to figure out the best trick to get a cleaner sound with the less CPU usage possible. I've actualy understood why my soustractive/additive bandlimited oscilators had some noise/clicking and it has nothing to do with aliasing but bad signal use in my design that I could fix easily.

Then while running my osc's with antialising/oversampling I did'nt notice an audible difference with or without antialising/oversampling, at least for the soustractive and additive synthesis. For FM synthesis I ran different test and got a good CPU use/antialising solution when oversampling two times. In order to get the best performance possible I could only apply the antialising method when using my FM osc and not applying it to my banlimited oscilators.

I've also tested inscreasing my block values and the result are interesting though I've heard that doing so leads to increase latency and since I want to make a patch meant for live performance it could became an issue if I rely on that to lower my CPU use. Though I might find a solution to the aliasing within use of a low pass filter which could offer a good alternative to the antialising method I used.

@gmoon I've used once pd~ and I don't know if I poorly implemented it or if the object isn't ready yet to deliver an interesting use of multiple cores but when I used it pd~ managed to multiply by four the CPU use of the patch I was working on. From my experience I won't recomend to anyone using pd~ for CPU optimization but maybe there's someone out there that knows how to use it properly and had succesfully devided his sound processing within pd.

NoxSiren is a modular synthesizer system where the punishment of failure is the beginning of a new invention.

--DOWNLOAD-- NoxSiren for :

• Pure Data :
  NoxSiren v15.rar
  NoxSiren v14.rar

• Purr Data :
  NoxSiren v15.rar
  NoxSiren v14.rar

--DOWNLOAD-- ORCA for :

• x64, OSX, Linux :
  https://hundredrabbits.itch.io/orca

In order to connect NoxSiren system to ORCA system you also need a virtual loopback MIDI-ports:

--DOWNLOAD-- loopMIDI for :

• Windows 7 up to Windows 10, 32 and 64 bit :
  https://www.tobias-erichsen.de/software/loopmidi.html

#-= Cyber Notes [v15] =-#

• added BORG-IMPLANT module.
• introduction to special modules.
• more system testing.

#-= Special Modules [v15] =-#

• BORG-IMPLANT (connects ORCA MIDI system to NoxSiren system)

#-= Current Modules [v15] =-#

• VCO (voltage-controlled-oscillator)
• VCO2 (advance voltage-controlled-oscillator)
• WAVEBANK (additive synthesis oscillator)
• ADSR (Attack-Decay-Sustain-Release envelope)
• C-ADSR (Curved Attack-Decay-Sustain-Release envelope)
• CICADAS (128 steps-Euclidean rhythm generator)
• CICADAS-2 (advance 128-steps polymorphic-Euclidean rhythm generator)
• COMPRESSOR (lookahead mono compressor unit)
• DUAL-COMPRESSOR (2-channel lookahead mono compressor unit)
• STEREO-COMPRESSOR (lookahead stereo compressor unit)
• MONO-KEYS (virtual 1-voice monophonic MIDI keyboard)
• POLY-KEYS-2 (virtual 2-voice polyphonic MIDI keyboard)
• POLY-KEYS-3 (virtual 3-voice polyphonic MIDI keyboard)
• POLY-KEYS-4 (virtual 4-voice polyphonic MIDI keyboard)
• POLY-KEYS-5 (virtual 5-voice polyphonic MIDI keyboard)
• POLY-KEYS-6 (virtual 6-voice polyphonic MIDI keyboard)
• BATTERY (simple manual triggered machine for drumming.)
• REVERB (reverb unit with lowpass control)
• STEREO-REVERB (stereo reverb unit with lowpass control)
• RESIN (advanced rain effect/texture generator)
• NOISE (generates black,brown,red and orange noise)
• NOISE2 (generates yellow,blue,pink and white noise)
• COBALT (6-stage polyrhythm generator)
• SHAPER (basic shaper unit)
• FOLDER (basic wave folding unit)
• STEREO-FOLDER (stereo wave folding unit)
• DUAL-FOLDER (advance wave folding unit)
• POLARIZER (transform a signal into bi-polar, uni-polar, inverted or inverted uni-polar form)
• CLOCK (generates a BPM clock signal for sequencing other modules)
• CLOCKDIVIDER (a clock divider with even division of clock signal)
• CLOCKDIVIDER2 (a clock divider with odd division of clock signal)
• DELAY-UNIT (delay unit)
• STEREO-DELAY (stereo delay unit)
• CHORUS (chorus unit)
• STEREO-CHORUS (stereo chorus unit)
• SEQ (advance 16-step/trigger sequencer)
• KICK (synthesize kick unit)
• KICK2 (synthesize flavor of KICK module)
• KICK3 (synthesize flavor of KICK module)
• SNARE (synthesize snare unit)
• CLAP (synthesize clap unit)
• CYMBAL (synthesize cymbal unit)
• RAND (RNG generator for other modules parameters)
• FMOD (feedback modulation unit)
• AM (amplitude modulation unit)
• RM (ring modulation unit)
• LFO (low-frequency-oscillator)
• LFO2 (advance low-frequency-oscillator)
• COMBINATOR (combine two waves)
• COMBINATOR2 (combine three waves)
• COMBINATOR3 (combine four waves)
• STRING (Karplus-Strong string synthesis unit)
• STRING2 (advance Karplus-Strong string synthesis unit)
• DETUNER (parametric 4-channel detuner unit)
• CRUSHER (basic audio resolution unit)
• STEREO-CRUSHER (basic stereo audio resolution unit)
• DUAL-CRUSHER (advance audio resolution unit)
• FILTER (basic filter)
• VCF (voltage-controlled-filter)
• MAR (Moog-analog-resonant filter)
• VCA (voltage-controlled-amplifier)
• DUAL-VCA (advance voltage-controlled-amplifier)
• FMUX (multiplexer with fast A/D internal envelope)
• MMUX (multiplexer with medium A/D internal envelope)
• SMUX (multiplexer with slow A/D internal envelope)
• FDMX (demultiplexer with fast A/D internal envelope)
• MDMX (demultiplexer with medium A/D internal envelope)
• SDMX (demultiplexer with slow A/D internal envelope)
• MIXER (mix 1-4 possible waves)
• SCOPE (oscilloscope analyzer)
• MASTER (fancy DAC~)
• BOX (useless decorative module)

NoxSiren integrated modules menu system.

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

Hello,

this is going to be a long one.
After years of using PD, I am still confused about its' timing and schedueling.

I have collected many snippets from here and there about this topic,
-wich all together are really confusing to me.

*I think it is very important to understand how timing works in detail for low-level programming … *

(For example the number of heavy jittering sequencers in hard and software make me wonder what sequencers are made actually for ? lol )

This is a collection of my findings regarding this topic, a bit messy and with confused questions.

I hope we can shed some light on this.

---

• a)
  The first time, I had issues with the PD-scheduler vs. how I thought my patch should work is described here:
  https://forum.pdpatchrepo.info/topic/11615/bang-bug-when-block-1-1-1-bang-on-every-sample

The answers where:

„
[...] it's just that messages actually only process every 64 samples at the least. You can get a bang every sample with [metro 1 1 samp] but it should be noted that most pd message objects only interact with each other at 64-sample boundaries, there are some that use the elapsed logical time to get times in between though (like vsnapshot~)
also this seems like a very inefficient way to do per-sample processing..
https://github.com/sebshader/shadylib http://www.openprocessing.org/user/29118
seb-harmonik.ar posted about a year ago , last edited by seb-harmonik.ar about a year ago 
• 1 
 whale-av 
@lacuna An excellent simple explanation from @seb-harmonik.ar.
Chapter 2.5 onwards for more info....... http://puredata.info/docs/manuals/pd/x2.htm
David.
“

There is written: http://puredata.info/docs/manuals/pd/x2.htm

„2.5. scheduling 
Pd uses 64-bit floating point numbers to represent time, providing sample accuracy and essentially never overflowing. Time appears to the user in milliseconds. 
2.5.1. audio and messages 
Audio and message processing are interleaved in Pd. Audio processing is scheduled every 64 samples at Pd's sample rate; at 44100 Hz. this gives a period of 1.45 milliseconds. You may turn DSP computation on and off by sending the "pd" object the messages "dsp 1" and "dsp 0." 
In the intervals between, delays might time out or external conditions might arise (incoming MIDI, mouse clicks, or whatnot). These may cause a cascade of depth-first message passing; each such message cascade is completely run out before the next message or DSP tick is computed. Messages are never passed to objects during a DSP tick; the ticks are atomic and parameter changes sent to different objects in any given message cascade take effect simultaneously. 
In the middle of a message cascade you may schedule another one at a delay of zero. This delayed cascade happens after the present cascade has finished, but at the same logical time. 
2.5.2. computation load 
The Pd scheduler maintains a (user-specified) lead on its computations; that is, it tries to keep ahead of real time by a small amount in order to be able to absorb unpredictable, momentary increases in computation time. This is specified using the "audiobuffer" or "frags" command line flags (see getting Pd to run ). 
If Pd gets late with respect to real time, gaps (either occasional or frequent) will appear in both the input and output audio streams. On the other hand, disk strewaming objects will work correctly, so that you may use Pd as a batch program with soundfile input and/or output. The "-nogui" and "-send" startup flags are provided to aid in doing this. 
Pd's "realtime" computations compete for CPU time with its own GUI, which runs as a separate process. A flow control mechanism will be provided someday to prevent this from causing trouble, but it is in any case wise to avoid having too much drawing going on while Pd is trying to make sound. If a subwindow is closed, Pd suspends sending the GUI update messages for it; but not so for miniaturized windows as of version 0.32. You should really close them when you aren't using them. 
2.5.3. determinism 
All message cascades that are scheduled (via "delay" and its relatives) to happen before a given audio tick will happen as scheduled regardless of whether Pd as a whole is running on time; in other words, calculation is never reordered for any real-time considerations. This is done in order to make Pd's operation deterministic. 
If a message cascade is started by an external event, a time tag is given it. These time tags are guaranteed to be consistent with the times at which timeouts are scheduled and DSP ticks are computed; i.e., time never decreases. (However, either Pd or a hardware driver may lie about the physical time an input arrives; this depends on the operating system.) "Timer" objects which meaure time intervals measure them in terms of the logical time stamps of the message cascades, so that timing a "delay" object always gives exactly the theoretical value. (There is, however, a "realtime" object that measures real time, with nondeterministic results.) 
If two message cascades are scheduled for the same logical time, they are carried out in the order they were scheduled. 
“ 

[block~ smaller then 64] doesn't change the interval of message-control-domain-calculation?,
Only the size of the audio-samples calculated at once is decreased?
Is this the reason [block~] should always be … 128 64 32 16 8 4 2 1, nothing inbetween, because else it would mess with the calculation every 64 samples?
How do I know which messages are handeled inbetween smaller blocksizes the 64 and which are not?

How does [vline~] execute?
Does it calculate between sample 64 and 65 a ramp of samples with a delay beforehand, calculated in samples, too - running like a "stupid array" in audio-rate?

While sample 1-64 are running, PD does audio only?

[metro 1 1 samp]  

How could I have known that? The helpfile doesn't mention this. EDIT: yes, it does.
(Offtopic: actually the whole forum is full of pd-vocabular-questions)
How is this calculation being done?
But you can „use“ the metro counts every 64 samples only, don't you?

Is the timing of [metro] exact? Will the milliseconds dialed in be on point or jittering with the 64 samples interval?
Even if it is exact the upcoming calculation will happen in that 64 sample frame!?

---

• b )
  
  There are [phasor~], [vphasor~] and [vphasor2~] … and [vsamphold~]
  https://forum.pdpatchrepo.info/topic/10192/vphasor-and-vphasor2-subsample-accurate-phasors

“Ive been getting back into Pd lately and have been messing around with some granular stuff. A few years ago I posted a [vphasor.mmb~] abstraction that made the phase reset of [phasor~] sample-accurate using vanilla objects. Unfortunately, I'm finding that with pitch-synchronous granular synthesis, sample accuracy isn't accurate enough. There's still a little jitter that causes a little bit of noise. So I went ahead and made an external to fix this issue, and I know a lot of people have wanted this so I thought I'd share. 
[vphasor~] acts just like [phasor~], except the phase resets with subsample accuracy at the moment the message is sent. I think it's about as accurate as Pd will allow, though I don't pretend to be an expert C programmer or know Pd's api that well. But it seems to be about as accurate as [vline~]. (Actually, I've found that [vline~] starts its ramp a sample early, which is some unexpected behavior.)
[…]
“

---

• c)
  
  Later I discovered that PD has jittery Midi because it doesn't handle Midi at a higher priority then everything else (GUI, OSC, message-domain ect.)

EDIT:
Tryed roundtrip-midi-messages with -nogui flag:
still some jitter.
Didn't try -nosleep flag yet (see below)

---

• d)
  
  So I looked into the sources of PD:

scheduler with m_mainloop()
https://github.com/pure-data/pure-data/blob/master/src/m_sched.c

And found this paper

Scheduler explained (in German): 

https://iaem.at/kurse/ss19/iaa/pdscheduler.pdf/view

wich explains the interleaving of control and audio domain as in the text of @seb-harmonik.ar with some drawings
plus the distinction between the two (control vs audio / realtime vs logical time / xruns vs burst batch processing).
And the "timestamping objects" listed below.

And the mainloop:

Loop
- messages (var.duration)
- dsp (rel.const.duration)
- sleep

With
[block~ 1 1 1]
calculations in the control-domain are done between every sample? But there is still a 64 sample interval somehow?
Why is [block~ 1 1 1] more expensive? The amount of data is the same!? Is this the overhead which makes the difference? Calling up operations ect.?

---

Timing-relevant objects
from iemlib:

[...]
iem_blocksize~   blocksize of a window in samples
iem_samplerate~  samplerate of a window in Hertz 


------------------ t3~ - time-tagged-trigger --------------------
-- inputmessages allow a sample-accurate access to signalshape --
t3_sig~          time tagged trigger sig~
t3_line~         time tagged trigger line~


--------------- t3 - time-tagged-trigger  ---------------------
----------- a time-tag is prepended to each message -----------
----- so these objects allow a sample-accurate access to ------
---------- the signal-objects t3_sig~ and t3_line~ ------------
t3_bpe           time tagged trigger break point envelope
t3_delay         time tagged trigger delay
t3_metro         time tagged trigger metronom
t3_timer         time tagged trigger timer

[...]

What are different use-cases of [line~] [vline~] and [t3_line~]?
And of [phasor~] [vphasor~] and [vphasor2~]?

When should I use [block~ 1 1 1] and when shouldn't I?

[line~] starts at block boundaries defined with [block~] and ends in exact timing?
[vline~] starts the line within the block?
and [t3_line~]???? Are they some kind of interrupt? Shortcutting within sheduling???

---

• c) again)
  

https://forum.pdpatchrepo.info/topic/1114/smooth-midi-clock-jitter/2

I read this in the html help for Pd: 
„
MIDI and sleepgrain
In Linux, if you ask for "pd -midioutdev 1" for instance, you get /dev/midi0 or /dev/midi00 (or even /dev/midi). "-midioutdev 45" would be /dev/midi44. In NT, device number 0 is the "MIDI mapper", which is the default MIDI device you selected from the control panel; counting from one, the device numbers are card numbers as listed by "pd -listdev."
The "sleepgrain" controls how long (in milliseconds) Pd sleeps between periods of computation. This is normally the audio buffer divided by 4, but no less than 0.1 and no more than 5. On most OSes, ingoing and outgoing MIDI is quantized to this value, so if you care about MIDI timing, reduce this to 1 or less.
„

Why is there the „sleep-time“ of PD? For energy-saving??????
This seems to slow down the whole process-chain?

Can I control this with a startup flag or from withing PD? Or only in the sources?

There is a startup-flag for loading a different scheduler, wich is not documented how to use.

---

• e)
  
  [pd~] helpfile says:

ATTENTION: DSP must be running in this process for the sub-process to run. This is because its clock is slaved to audio I/O it gets from us!

Doesn't [pd~] work within a Camomile plugin!?

How are things scheduled in Camomile? How is the communication with the DAW handled?

---

• f)
  
  and slightly off-topic:
  There is a batch mode:
  https://forum.pdpatchrepo.info/topic/11776/sigmund-fiddle-or-helmholtz-faster-than-realtime/9

---

EDIT:

• g)
  I didn't look into it, but there is:
  https://grrrr.org/research/software/

clk – Syncable clocking objects for Pure Data and Max
This library implements a number of objects for highly precise and persistently stable timing, e.g. for the control of long-lasting sound installations or other complex time-related processes.

---

Sorry for the mess!
Could you please help me to sort things a bit? Mabye some real-world examples would help, too.

gene-seq-to-music-via-pd~-help.pd
gene-seq-to-music-via-pd~.pd

DNA Sequence (Nucleotide) Player: Converting nucleotide sequences to (midi) Music

Credits:

All source data is retrieved from the "Nucleotide Database" (DB) via National Center for Biotechnology Information, U.S. National Library of Medicine (NCBI) at
https://www.ncbi.nlm.nih.gov/nucleotide/

Miller Puckette for the J08.classicsynth

and

the creator(?) of the vlist2symbol abstraction.

Requirements:

wget, Linux command line web retrieval tool
Linux
ggee, [shell]
cyclone, [counter]

Use Case:

Actors: those who want to hear the patterns in DNA nucleotide sequences and/or comprehend how Nature makes Music not "noise"/Gene sequences are like one of Nature's "voices"/

Case:
Enter the "Accession" (identification number (id)) of a NCBI DB entry into the id symbol field

Case:
Click on "LOAD"

Case:
Click "PLAY".

Instructions:

1-Go to the DB (https://www.ncbi.nlm.nih.gov/nucleotide/) and find an Accession(id) of a sequence;
2-Enter that value into the ID [symbol] box of the patch
3-Click the "LOAD" [button/bang];
4-Set pitch, velocity, duration, and repeat for G,A,C, and T (representing the four nucleotide bases of a DNA strand — guanine, cytosine, adenine, and thymine);
5-Toggle "PLAY" to 1, i.e. to On, to hear the sequence using the variables you set in 4) and to "0" to stop it.

How It Works:

The patch takes the input ID and packs it into a string as the FILE(Path) for wget.

The wget command is then sent as a list to a shell object.

The output of the shell object is then parsed (using an intermediate [text] object) into a [text] object with each line being 4 characters long, each character being either G,C,A, or T.

Once loaded and Play is clicked, each line is then reconstructed as a midi note with the pitch as determined by the first character, velocity (2nd) and duration (3rd) and repeated as many times as the 4th character dictates (as set in 4) above).

Once the entire sequence is played, the player stops sending notes.

Inlets(left to right):

id, either numbers or symbols
values, a 16 item list of 4x4 sets of pitch, velocity, duration, repeat (i.e. one set per nucleotide type, G,C,A, or T) (Note: the sequence, if loaded, will play immediately upon receipt of this list.)
beats per minute, bpm, esp. as it relates to note durations.

Outlets:
the current midi note, i.e. pitch/velocity/duration
id (of the gene sequence)
sequence name, as listed by the NCBI DB
nucleotide being played as a string, ex. GGAC

AFTERWARD:

1. Since it really is only sending midi value it can be connected to whatever synth you would like;

2. Elsewhere on this Forum, I shared a patch which took "noise" as its input and converted it into music using sigmund~, in that case "running water" as its source. (See for reference: https://forum.pdpatchrepo.info/topic/12108/converting-noise-to-music-rushing-water-using-sigmund) This patch takes that concept and applies it to what might also be called "noise", DNA sequences, were it not that the results (like the running water, yet even more so) sound like "Music".

This exploration has me wondering...

How can we delineate what is noise (only natural at this point) and what is music?

Is the creative/ordering/soulful nature's being expressed in our own music not also being expressed by Nature itself? ...so that we might be considered one "bow" playing upon it?

And, if by Music we mean notes laid down on purpose, might not it be said that is what Nature has been done? Is doing?

I hope you find the patch useful, stimulating, and exciting, or at the very least funny to think about.

Love through Music, no matter in what state Life may find you,
Peace,
Scott

Hi Folks,

I thought I’d share this patch in the hopes that someone might be able to help improve upon it. I am by no means even semi competent with PD and jumped into this task without actually bothering to learn the basics of PD or RPi, but nevertheless here we are: maybe you can share a better implementation.

Mods/experienced folks, if I am sharing irrelevant/wrong/confusing info, mea culpa and please correct me.

I wanted to make a patch for PD in Raspberry Pi that would do 3 things:

• Get the abl_link~ temp data over wifi
• Create a midi clock output using a 5-pin midi adapter (I have one of the cheapo usb-to-midi cable things here)
  -simultaneously create an audio pulse ‘clock’ output such as those used by volcas, Teenage Engineering Pocket operators, and the like (I am not sure if such an audio signal over a 3.5mm jack would be hot enough to be considered a CV pulse too, maybe you can help clear that up?)

As I say, after much struggles I have globbed something together that sort of does this.

A couple of things for newcomers like myself:

The abl_link~ object in the patch isn’t initially part of the standard pure data install as I write. I was able to use deken (ie the code that powers the ‘help/find externals’ bit of PD) to look for abl_link~. Search for it. At the time of writing there is a version for Arm7 devices like the Raspberry Pi 3 which was put together by the illustrious mzero with code from antlr. Go ahead and install the abl_link~ object. (Possibly you may have to uncheck the ‘hide foreign architectures’ box to get the arm7 version to show up. This is usually a safeguard to stop users from trying to install versions of externals that won’t work on their systems. So long as you see ‘arm7’ in the description it should hopefully be the one you want) PD will ask where you want to store the external, and I would just leave it at the default unless you have a special reason to do otherwise.

To get the patch to hook up to your preferred audio and midi outputs by default you may have to take certain steps. In my version of it I have deemed the built in audio and my cheapo USB midi output to be good enough for this task.

[As part of my troubleshooting process I ended up installing amidiauto which is linked to here: https://community.blokas.io/t/script-for-launching-pd-patch-with-midi-without-aconnect/1010/2
I undertook several installations in support of amidiauto which may be helping my system to see and link up my USB midi and PD, but nothing worked until I took the step in the following paragraph about startup flags in PD. (It may also be that I did not need to put in amidiauto at all. Maybe I’ll try that on another card to see if it simplifies the process. I’m saying you might want to try it without amidiauto first to see).]

Midi: - (ALSA is the onboard audio and midi solution that is part of Raspbian). To have PD use ALSA midi at the start I made the following setting in the preferences/startup dialog - within that window there is a section (initially blank) for startup flags. Here you can set instructions for PD to take note of when it starts up. I put in -alsamidi to tell it that alsamidi will be my preferred midi output. (I also took the step of going to file/preferences/midi settings, then ‘apply’ and ‘ok’ to confirm the Alsa midi ports that showed up. Then I went back to file/preferences/save all preferences. This seems to have (fingers crossed) saved the connection to my USB midi output.

Audio: I used the terminal and sudo raspi-config to set my audio out to the internal sound card (advanced options/audio/3.5mm jack). Since I had a fairly unused installation of PD I’d never asked it to do anything but work with the system defaults so getting audio out was fairly simple.

[nb I initially stuck this patch together on my Mac where everything worked pretty trouble free in terms of audio and midi selection]

About the patch. Obviously it is sort of horrible but there it is. It is a combination of stuff I cribbed from the demo example of abl_link~ in the example, and two example patches created by users NoDSP and jpg in this forum post https://forum.pdpatchrepo.info/topic/9545/generate-midi-clock-messages-from-pd/2
As well as some basic synthesis to make the bip bip noises I learned from LWMs youtube channel
https://www.youtube.com/channel/UCw5MbnaoDDuRPFsqaQpU9ig

Any and all errors and bad practice are mine alone.
The patch has some comments in it that doubtless expose my own lack of understanding more than anything. Undoubtedly many users can do a better job than I can.

Some observations on limitations/screwups of the patch:

• If you disconnect from the stream for a bit, it will attempt to catch up. There will be a massive flurry of notes and/or audio bips as it plays all the intervening notes.

• It doesn’t seem to be too fussy about where in the bar it is getting started (It will be "on" the beat but sometimes the ‘1’will be the ‘2’ etc. This is okay if I’m using internal sequencers from scratch (in the volca, say) but not if there is an existing pattern that I am trying to have come in 'on the 1'.

• My solution to more detailed subdivision of bars was to make a big old list of numbers up to 32 so that abl_link~ can count up to more than 4. There’s probably a better solution for this. If you find that you need even more subdivisions because you are making some sort of inhumanly manic speed gabba, add even yet more numbers and connections.

I haven’t tested this much. And since it’s taken me the better part of 18 months to do this at all, I’m really not your guy to make it work any better. I’m posting here so that wiser souls can do a better job and maybe share what I think has the potential to be a useful midi sync tool.

I plan to revisit https://community.blokas.io/t/script-for-launching-pd-patch-with-midi-without-aconnect/1010/3
for some pointers on setting this up to launch the patch at startup to give me a small, portable midi Link sync device for 5-pin and audio-pulse clocked devices.

This is my first ever bit of quasi productive input to any technical community (mostly I just hang around asking dumb questions… So be kind and please use your giant brains to make it better) I look forward to spending some time learning the basics now. link-sync.pd

@cuinjune I tried to compile the lissa seq patch. but when i open the executable it opens only a small empty window.
i also tried to compile a help patch for testing, with the same result.
but your example works fine(Win32Example).

Hi All
A little bit of work to set up but forget midi mapping...google it if you dont believe me.
After a lot of time spent trying to get a simple but sophisticated way (using a minimal 8 button floorboard) to control Live on w10, I thought I would share this particular solution to possibly help others (especially after the help offered here on this forum). I tried a number of scenarios, even buying Max 4 Live, but it turns out a lot simpler than that. It needs 3 main areas set

FOOT CONTROLLER BEHAVIOURS/GESTURES
Create pd patch that gives you 'behaviours' per switch. Ill be happy to share mine but Im just cleaning them up atm.
eg I have 4 standard behaviours that dont take too much time to master

1. Action A: A quick click (less than 500ms) Always the primary action
2. Action B: Long click ie 1 click down and pedal up after 500ms. I use this eg always as a negative ramp down for things like lowering volume but if its just held down and released in a natural way, it is the secondary action of the switch
3. Action C: 3 Click ie 1 quick down, up and then hold down. I use this for a positive ramp eg as volume up
   4 Actiion D: Double click, Always a cancel
   These are all mapped to note/ctrl outs that match the 'Selected Track Control' below

PLUGIN
Use PD VST to create a plugin version of your patch. This is loaded into Live as a control track. Live manages the connection of your floor board etc into the actual track so you dont wrestle with the io. I always use track 1 for click (forget Live metronome, this is much more flexible and can have feel/swing etc) so I dedicate track 2 to control.
Use LoopMIDI to create a virtual midi cable that will go from this track and be fed into the remote script.

REMOTE SCRIPT: 'Selected Track Control'
Download latest from http://stc.wiffbi.com/
Install to live and make sure your notes/control conform.
Enable this as a control surface in live and connect midi in from the plugin. Think about giving the guy a donation...massive amount of work and he deserves it!

I use it to control 8 tracks x 8 scenes and is controlled by 3 switches

1. Scene control up and down (A = down, B = up)
2. Track control same as scene
3. Rec/Fire/Undo Volume up and down (A = fire/rec, B = Volume Down, C = Volume Up, D (Dbl Click) = Undo

The scenes and tracks wrap so there isnt too much foot tapping

There is quite a bit more to it of course...its and maybe no one else needs this but it would have saved me a couple of weeks of time so Im happy to help anyone wanting to achieve gigging without a massive floor rig and an easy way to map and remember.

HTH someone

Cheers
mark

Time to start contributing some knowledge back to the wonderful world that is the internet; today, a step by step nice and easy tutorial on getting started to building your own MIDI controllers with the arduino.

When researching for my ableton controller project, I didn’t find much out there about using firmata on an arduino to send data to software. The standard approach just seemed to be create the code in the arduino language, upload it to your board and hack one of those MIDI to USB cables as a bodge job way of getting the MIDI out of the arduino.

So why firmata and pure data? Well the whole idea of firmata is that you flash it to your arduino, and it throws out serial about whats going on with the arduino inputs and outputs, then you decide how the software treats the readings coming in and going out.

Theory out the way, lets build some controllers. You’ll need a few things…

HARDWARE:

An arduino and something to wire into it (for this i’ll be using a pot)
A USB cable for your arduino
SOFTWARE:

Arduino – http://arduino.cc/en/Main/Software
Pure Data – http://puredata.info/downloads
Firmata – http://at.or.at/hans/pd/objects.html#pduino
Something to patch your new controller into; like Reason or Ableton Live

1. SETTING UP FIRMATA AND PURE DATA

Install Pure Data and create a folder to store all your patches somewhere. Unzip Firmata and add the files ‘arduino.pd’, ‘arduino-test.pd’ and ‘arduino-help.pd’ to your new Pure Data folder. The ‘arduino.pd’ file is the object that we use in PD for opening up communication with your arduino and routing it to PD. Done? Awesome, your software is almost set up.

2. FLASHING FIRMATA TO YOUR ARDUINO

Install the latest version of arduino and open it up. Connect your arduino with the USB cable to your laptop (i’m using a macbook for this by the way). In the example patches, open up “Standard Firmata”, select your board (im using an arduino mega), and your serial port (look for tty.usbserial for use with a USB cable). Then compile and hit the upload button and your arduino is now ready to use firmata and communicate with Pure Data!

3. WIRING UP A POT

Potentiometers are cool, and theres a great arduino tutorial of how to wire one up here: http://www.arduino.cc/en/Tutorial/Potentiometer

Basically, all you need to know is that there are three pins; your two outer pins govern voltage flow across the pot, meaning one has to be 5V and the other has to be ground. It doesn’t matter which, but your 5v pin is going to be where your pot reads maximum, so convention dictates this should be the right hand pin. The center pin needs to be connected to an analog in on the arduino and will read the value of the pot as it sweeps from ground (0v) to 5v.

All wired up? Plug it into your laptop and open Pure Data, we’re ready to get things talking.

4. SETTING UP OUR PATCH

Open the example “arduino-test.pd” Pure Data patch you copied over earlier. It should look like this one…

The test patch has everything we need to open a connection and enable pins. Firstly, lets delete a bunch of stuff and make our window a bit bigger. Hit Command + E to enter edit mode in Pure Data.

Ok a quick explaination; the key component here is the ‘arduino’ object. This is being drawn from the file you copied in earlier, and is what communicated with your arduino. Here we can do everything to control the arduino from opening a connection, to receiving data.
The large grid allows us to set the mode of each pin on the arduino. Remember pins 0 and 1 are reserved for Rx and Tx. I’m using analog pin 4 for this demo, so I’ve set my pin mode for pin 4 to ‘analog’.

Now we can plug our arduino in and get a reading from the potentiometer.

5. ARDUINO INTO PURE DATA

With your arduino plugged in, hit command and E to bring us out of edit mode. In our patch, click on ‘Devices’ above the arduino object and open up the pure data terminal. (That other thing that loads with PD that has all the scary code in)

The “Devices” message connected to the arduino object pings your computer to find what devices are connected and on what serial ports. Since we’re using a USB cable to connect our arduino, we’re looking for something with ‘usbserial’ in it, in this case; port 2.

Select the relevent port in the green box at the top (remember the first box is ‘0’, second is ‘1’ and so forth) and hit ‘Open’ to establish a connection. Check the terminal to see if the connection was sucessful.

Now lets check we’re getting something in. Create a number box (Command + 3) and connect it to the relevent pin on the ‘Route analog’ box at the bottom. In this case, pin 4.

One more thing; if you’re not getting any readings in, you’ll need to click on ‘pd old analog/digital controls’ and enable your pins here too. What I tend to do in my patches is just not include the large grid but make my own ‘old pd’ controls custom to what i’m enabling/disabling to save space.

Here’s what the ‘old analog/digital controls’ subpatch looks like (pin 4 enabled)…

Come out of edit mode and check that you’ve got readings. If so congratulations! If not, troubleshoot, start with making sure your usb connection is opened, make sure all the correct pins are enabled (remember you’re counting from 0 not 1 on most of these buttons in PD, it’s just the way computers work).

6. SCALING READINGS TO MIDI

So we’ve got a reading and chances are it’s to 3 decimal places between 0 to 1. No problem, create a new object (Command + 1) and type “autoscale 0 127”. This allows us to scale the input to a min and max value, in this case 0 to 127 of MIDI. Next, lets get things looking nice, create a new object and type “knob”. Connect this AFTER the autoscale object. (the knob is default set to read inputs from 0 to 127. Then create another number to display the scaled MIDI data coming out, and finally a new object and type “ctlout 1”.

It should look something like this…

The second box should be outputing values from 0 – 127 now, and the knob giving a visual representation of your potentiometer.

Now lets patch it into ableton…

7. PURE DATA TO ABLETON LIVE

Firstly, you’ll need to set up your macs IAC driver if you’ve not done this. Basically you’ll need to go into Audio/MIDI preferences and enable your IAC driver. Then create a new input and output. One for input to DAW and one for output from DAW. Google around for a tutorial on this, its really simple, a 30 second job.

After you’ve set up your IAC driver, go back to PD and go to preferences > MIDI Settings, and connect your IAC driver.

Open ableton and go to its MIDI preferences. Create a device listing for your IAC driver and enable its ins and outs into ableton like so…

And thats it! Create an instrument and try to assign something! I’ve got it controlling the brightness of a bass sound here.

Shout out for Facu who requested this tutorial. Hopefully it’ll help some of you looking to get into this stuff and start building things but with no idea where to start.