Losing a midi device is a major pain in any kind of live situation.

In windows and mac audio software will only see what midi hardware exists when it is first loaded - so if you plug something in after PD was opened it won't be available. It's just some legacy "its always been this way" bs, midi has been around for a very long time. Maybe midi 2.0 takes care of this? Ive had no interest in it

What I do is use a virtual port - in windows loopMidi and on mac digging deep in to the audio/midi settings to check the UAC connection to be on. on both I will rename the virtual ports to something sane like where its meant to go, or come from, or what its meant to do because virtual ports can be misused as they talk bidirectionaly (hardware midi only works in one direction - typically its an Out creating notes, ccs, etc meant to be received to a software programs In)

The magic secret sauce is combining a virtual port with a routing program, on windows Midi-OX because it remembers each instance and their filters, connections - so when I accidentally yank a usb out I can just plug it back in and close/reopen it and the software won't have any problems except maybe a stuck note. on mac midi monitor or midi patchbay it looks like midi monitor refreshes on the fly so you can set it to act as a destination, and then tick the hardware on and off as it shows up (as long as its running before you launch your audio program there's no need to mess with the virtual UAC port either).

This approach could also be done through the shell with python or some automation but it's never been a problem enough for me to look into

@pholypp Soundcards is a difficult one to nail.
I have had a Motu 828 that would run for hours without any problem and then suddenly produce spikes on some or all outputs until a preset was reloaded (much quicker than a reboot).... and then be happy for days until the next time. The driver settings would often not stick when changed..... reopening the driver panel the settings would have changed to something else, but serial data streams have to be negotiated so...?

Other Motu's (different drivers) have never had a problem.
I don't think they are manufactured with problems, or that the 828 had any electronic faults.
It is much more likely that the 828 driver had problems talking to the os, On my mac the keyboard and the trackpad and the CD drive are all on the same hubs as the USB ports, which cannot help.

Some USB soundcards will work on one USB port but not on another, probably because something else (keyboard, something?) is on the same bus and so the bus timing has been downgraded to USB 1 from 3 or 2

Trial and error all the time....... especially with the Adobe updater, where I had force stopped just about every service on the laptop in desperation. Adobe updater always ran as a delayed start service at boot. Adobe licensing also, but fortunately without causing problems.

I am no expert in such things, but with so much software trying to control so much hardware nowadays how can anyone be sure....
It's a bit like a doctor having to hope that you can take aspirin + X when you have Y and Z but they don't yet know what Z is.
It seems to me that if it is mission critical then it should be bare bones and never receive an update.
I don't ever connect my show laptops to the internet.
David.

@60hz You might be able to redirect a comport to your cheap usb device.
It is possible in windows using.......
NET USE COM1: //pc_name/printer_share_name /persistent:yes
The usb device has to be shared first......
https://superuser.com/questions/923426/how-to-map-a-virtual-com-port-to-a-physical-usb-port
The proviso about plain text would not bother you for a dmx dongle.

Further down the same thread you will see a link to https://ftdichip.com/drivers/vcp-drivers/
..... and on that page the virtual drivers for windows.
They mention "D2XX Direct drivers" are included...... and I have a very vague recollection that it is they that do the FUDI stuff.
They only mention windows....... and then further down the page are drivers signed by Apple, and quite a few others.

The virtual drivers should make the device appear as a comport.
You can see on Amazon that a few people needed these virtual drivers to make the device you have work with FreeStyler....... where they then select Enntec DmxPro as the output.

In Freestyler selecting the Enntec is essentially choosing to communicate through a comport rather than through a driver interface.
When you select the DMX Pro in Freestyler it asks which comport (years since I have used it... but pretty sure)
David.

P.S. I forgot to mention yesterday that you could send your data directly from the RPI using Python (maybe Python is already involved) and call pdsend....... probably pdsend.linux which is in the Pd folders somewhere.
That would send directly over Ethernet to a [netreceive] on your computer.
Approximate usage..... https://guitarextended.wordpress.com/2012/11/03/make-python-and-pure-data-communicate-on-the-raspberry-pi/
I assume (I do that a lot) that
pdsend (your computer IP address):(port) would send correctly...... something like pdsend 192.168.1.33:3000 would send to [netreceive 3000] on your computer.

You mentioned an Ethernet shield...... does your RPI not have an Ethernet port built in ?...... I thought they all have one.

Hello, first of all I want to say that I have been using Pd for 6 years on a PC i5 (fourth generation) 16gb ram and Windows 7 ultimate. Pd and other DAWs I have have always worked without any stability problems. A year ago I upgraded to Windows 10 home (I have always optimized Windows following the indications offered by Merging Technologies and some professional DAWS) Today all the software related to audio works perfectly and without any problem except PS that drives me crazy.

Just create a new patch with 2-3 tables and 2-3 signal objects to start the instability in Pd.
The first symptom that appears is the "feeling" of "overloaded". For example, when dragging an object with the mouse, the object is delayed with respect to the mouse pointer (the more the object patch is loaded, the more noticeable the delay is)

If I save the content of a table of only 8820 samples for example (200ms) with [soundfiler], it can take between 2 and 3 seconds to wait until the message appears in the console

It has also happened to me (although on fewer occasions) that when I press a bang button, the button remains pressed in black and Pd blocked (although I am not aware that this problem is directly related to the other comments).

I want to make it clear that I have not had any problems related to the audio, it is with the GUI that makes me think that something is not right. The first of the problems that I have named is the one that I consider serious for me, because it prevents me from working at ease and in the end I end up not going ahead with any patch. This happens to me in version 0.53.0 that I have now and in the previous 4 versions. I have used the same patches on a laptop that I have and everything works normally. I can't get to understand what is really happening and what the blissful problem may be related to, I have asked several Pd users on telegram and they have not been able to help me either...

Any ideas that occur to you will be welcome. Thank you!

@whale-av said:

@ingox Solving the users problem it seemed to me that Pd is seething with key/value pairs.

To be clear, I'm talking about dictionaries which are collections of key/value pairs. You can use a list, a symbol or even a float as a single makeshift key/value pair, but that's different than a dictionary. (Also known as an associative array.)

The headers/tags float, symbol etc. are used extensively as key/value for message routing.

This is a flat list where the first atom of the list acts as a selector. That's definitely a powerful data structure but it isn't an associative array.

[list] permits longer value strings.

These are variable-length lists, not associative arrays.

The problem for the OP was only that a series of key/value pairs had been stored as a list and that needed splitting.... but it's not a common problem..... and luckily the key was not also a float.

The OP's problem is instructive:

1. If you need to send a single key/value(s) pair somewhere in Pd, a Pd message will suffice.
2. If you need to store a bunch of key/value(s) pairs as a group (like an associative array does), a [text] object will allow you to do that with semi-colon separated messages. The important thing here is that the semi-colon has a special syntactic meaning in Pd, so you don't have to manually parse atoms in order to fetch a "line" of text.
3. If you want to send a group of key/value(s) pairs downstream, or you want to keep a history of key/value(s) pair groups, you have to start building your own solution and manually parsing Pd messages, which is a pain.

After doing a lot of front end work with Javascript in Purr Data, I can say that associative arrays help not only with number 3 but also number 2. For example, you don't have to search a Javascript object for a key-- you just append the key name after a "." and it spits out the value.

It may be that number 3 isn't so common in Pd-- I'm not sure tbh. But the design of the OP's data storage thingy doesn't look unreasonable. It may just be that those of us used to Pd's limitations tend to work around this problem from the outset.

The old [moonlib/slist] shared keys throughout a patch.
I used to use [slist] extensively as a dictionary, loading it from text files as necessary.

I'll have to play around with that one-- I'm not entirely sure what it does yet.

Keys are already a fundamental part of message passing/parsing.
And the correct way to store them as a string in Pd would have been with comma separators.
(I think...!! ...??)

I tend to use [foo bar, bar 1 2 3, bee 1 2 3 4 5 6 7( as a substitute for an associative array. But again, there's a limitation because you stream each message separately. E.g., if you have a situation where you route your "foo... bar... bee" thingy to some other part of the chain based on some condition, it's way easier to do that with a single message. But again, perhaps we're used to these workarounds and plan our object chains to deal with it.

David.

This seems as likely a subcategory as any...

I'd like to connect with teachers using Pure Data in the classroom.

• Where are the stumbling blocks that you see students crash into frequently?
  • (Anyone using Pd could chime in on that one... what are the things that confused you?)
• Are there any techniques/ideas/paradigms that helped the students to understand these difficulties more easily?

For a specific example: https://forum.pdpatchrepo.info/topic/13263/samphold-at-the-control-level -- "I want to get the number to update on the downbeat so it doesn't play anything while the number is being updated by some other process."

Extremely common scenario -- but I'll be danged if I can find anything in the help series that makes it clear.

This happens to be one of the sticking points for me -- which, lately, got me thinking about a paradigm of "feedforward" and "feedback" to cold inlets. It's (relatively) easy to understand chaining through hot inlets. Everything is immediate, and that's where the quoted question comes from -- if the only thing anyone taught you is how to chain immediate operations, then "save this datum for later" is scarcely even thinkable. (The quoted thread goes on to say "I'm having trouble explaining" -- meaning, whatever degree of exposure to Pd this user had, it wasn't enough to provide a vocabulary to talk about this problem.)

• "I have data now, but I don't want to use it until later" --> feed it forward to a storage object, then bang the storage object when you need it.
• "I want the next cycle of a loop to operate on the result of this cycle" --> feed it back to a storage object that's triggered by the loop.

This solves a bunch of problems. The quoted problem -- (data source) feeds forward to [f] right inlet. Or, initializing a counter at the beginning of the loop (feedforward). Or, building a list iteratively, but outputting only the final list (on each loop iteration, feed the list-in-progress forward to list storage, and bang the storage when the list is finished -- for this one in particular, I had struggled in the past with various bizarre usages of [spigot] but this is much easier).

One of the things I was missing over the last year and a half of getting up to speed in Pd is an established vocabulary of usage patterns. Sometimes I think Pd and Max pedagogy tries to stay away from typical computer-science problems -- but sooner or later, you're going to run into problems that have standard solutions. So why not collect them into a unified place? Like, in SC, for the fourth example below I can just write arrayOfMidiNotes.collect { |note| note.midicps } and uses of collect are all over the place in the help system... but in Pd, it took me literally over a year to figure out the best way to collect / map. That's... kinda crazy.

hjh

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.

I have to admit that I forgot to get the Mac screenshot yesterday (smh).

@oid said:

free of the weird artifacts which I assumed were caused by a post screen grab resize, but could have been caused by the screen grabber itself. Lines should not be changing thickness like that, most noticed on the line between [moses] and the number box, they should be 1 pixel wide but it alternates between 1 and 2 pixels in width.

That issue is not caused by the screen grabber. It's the normal appearance of Pd for ages. See the 2nd "Modulation index" --> [*~]. (This is a png -- there are no jpg compression artifacts. This is how it really looks on my screen, in the Pd window.)

"Lines should not be changing thickness like that" -- agreed, but by that standard, then Pd's line rendering is sub-par. Lines in Pd have always been changing thickness, for as long as I've ever used it.

It's a (more-or-less) solved problem in the graphics world. FWIW here is angled-line drawing in SuperCollider (using Qt). Here, I've chosen an angle that will be maximally fuzzy. It's not great exactly but, in my opinion, less distracting than Pd's current display.

whale-av quotes seb-harmonik: "Tk/Tcl has solutions in the pipeline" ... erm... but... again, it's a solved problem. Tcl/Tk hasn't caught up with the rest of the world.

@whale-av said:

Pd I use as a tool to get things done and how it looks is unimportant except for keeping patches clean and readable.

I do understand, but I don't quite agree that appearance is completely unimportant.

For a software community to thrive over the long haul, it needs to attract new users. If new users get turned off by an outdated surface presentation, then it's harder to retain new users.

I've observed, at times, when someone points out a deficiency in Pd, the Pd community's response often downplays, or denies, or gets defensive about the deficiency. (Not always, but often enough for me to mention it.) I'm seeing that trend again here. Pd is all about lines, and the lines don't look good -- and some of the responses are "this is not important" or (oid) "I like the fact that it never changed." That's... thoroughly baffling to me.

I know it's not going to change anytime soon, because the current options are a/ wait for Tcl/Tk to catch up with modern rendering or b/ burn Pd developer cycles implementing something that Tcl/Tk will(?) eventually implement or c/ rip the guts out of the GUI and rewrite the whole thing using a modern graphics framework like Qt. None of those is good (well, c might be a viable investment in the future -- SuperCollider, around 2010-2011, ripped out the Cocoa GUIs and went to Qt, and the benefits have been massive -- but I know the developer resources aren't there for Pd to dump Tcl/Tk). But there's a big difference between "we know it's a problem but can't do much about it" vs "it's not a serious problem." The former may invite new developers to take some initiative. The latter discourages initiative. A healthy open source software community should really be careful about the latter.

hjh

@Joseph-Mikkelson No, changing the samplerate will not help, except that matching it to the soundcard reduces the load on the cpu......but there are more important issues...... see below.....

I should have expanded on latency.
Using a live input [adc~] and doing some Pd processing effects and then sending that to speakers [dac~] latency is not so much of a problem. Often it involves delays anyway (echo, reverb, etc.) and our ears are used to that.
Latency for playback of an audio track, or generated audio, is no problem...... it is heard when it arrives at the speakers and that is all.
Problems arise when the input goes straight to the output....... as with a monitor mixer built in Pd for example..... with live acoustic instruments...... where the musician hears their own instrument acoustically and the same sound delayed in the monitor. Essentially a chorus effect is produced, caused by the latency, and that will make it harder for a violinist for example to pitch correctly.
Chorus in a reverb effect really upsets violinists..... anything much over 5ms.
Of course a massive latency...... 100ms+..... will cause timing problems even for a guitarist, and even if they are the rare musician that didn't have such issues in the first place.
I have met classical and jazz musicians that have learnt to dissociate what they play from what they hear...... for example playing through a delay, but in sync with everyone else...... so playing say 1 second before everyone else....... but......

SAMPLE RATE
You should match your samplerate to your soundcard, or you will have re-sampling artefacts....... usually a low level high pitched whine when your patch is not producing any sound.
It is slightly more complicated than that.
If you play an audio file that was recorded at 44.1KHz while the Pd samplerate is set to 48KHz it will play back at the wrong speed....... Pd will not resample it and so the pitch will be wrong.
It's a PITA.
So the Pd samplerate must be set to match all the audio files that you use in Pd.
To avoid the artefacts you then need to set your soundcard to match Pd.
Other programs will adjust..... so that is not a problem.
External cards can make that change through their control panel, and internal cards should have the option somewhere.
In windows it is here in the speaker control panel..... https://forum.pdpatchrepo.info/topic/12094/newbie-clipping-on-pure-data-portable-with-mmio/4
and I am pretty sure that windows always sets the on-board soundcard to 48KHz "out of the box".
David.

Hi!
I'm starting to learn Pd Extended and I trying to make a filter able to highpass, lowpass, both things or neither of them, but I'm having problems making a toggle to bypass the filters:
While in the highpass filter everything works fine (I can move the slider to the frequency I want, I can turn it off and I can turn it on again keeping the frequency I chose before), when I try to do the same on the lowpass filter, everytime I turn the toggle off (as a bypass), I stop hearing the sound.
Here is my configuration and my patch:

problem.pd

Thank you in advice!