It's hard to tell without knowing your setup. OS? Hardware?

I run PD vanilla on xubuntu 20.?? (latest LTS) and an external sound card/mixer (cheap behringer). I can get audio both with and without jack

If I set up PD to run just with ALSA (no jack) and I have some other programs running that are using the sound card (like a browser or whatever) PD will tell me:

ALSA input error (snd_pcm_open): No such file or directory
ALSA output error (snd_pcm_open): No such file or directory

However, closing my browser and/or other programs that route sound through ALSA solves this

Using jack instead gives me the advantage of running other DAW software along side PD and route both midi and audio back and forth between them (non jack programs will be silenced), but jack has to be set up properly for the server to run without dropouts (select the correct soundcard, buffer size etc in settings), or even start at all. For this purpose I use qjackctl, which is a GUI control panel for the jack server- should be in your distro's repositories.

The errors you get with jack simply states that the jack server is not running- it has to be started manually. You can do that with a command from your terminal or get the qjackctl software for the GUI (which I reckon you will prefer as a windows convert). Run: sudo apt install qjackctl from your terminal to install it if you are using a debian based distro (*ubuntu, mint et al)

@alexandros said:

Have you detected whether the crash happens with else if (in == 'd') or else if (in == 'p')?

It happens only in else if (in == 'p'). When I bypass that I can update snapshot~ by 1 ms (I assume that 'c' will still be sent by 1 ms intervals).

In the Pd patch it's probably better to swap the $1 and $2 values in the messages. Have the channel set in a cold inlet and the value in a hot one and then write this message print $2c$1v

Ok I did that.

I see in the screenshot of the patch that the PWM message is not connected to [comport]. Is this for some particular reason?

It is to make sure Pd does not crash/freeze until I want to try the code.

Maybe the 10ms interval for sending a PWM value to [comport] is a bit too fast. Did you try something slower, like 50ms?

That made it work. If I use six pwm pins the limit is 150 ms before crash.

Question 1: Could there something bad that happens around else if (in == 'p')? In another code snippet you used this format:

  while(Serial.available()){
    byte inByte = Serial.read();
    if((inByte >= '0') && (inByte <= '9'))
    temporary = 10 * temporary + inByte - '0';
    else{
      if(inByte == 'p'){
        pwmLEDvalue = temporary;
        temporary = 0;
      }
      else if(inByte == 'd'){
        dspLEDstate = temporary;
        temporary = 0;
      }
    }
    analogWrite(pwmLED, pwmLEDvalue);
    digitalWrite(dspLED, dspLEDstate);
  }

compared to this in the current sketch:

if (Serial.available()) {
     
    static int temp;
    byte in = Serial.read();
  
    if (isDigit(in)) temp = temp * 10 + in - '0';
    
    else if (in == 'c') {
      channel = temp;
      temp = 0;
    }
       
    else if (in == 'd') {
      digitalWrite(outPins[channel], temp);
      temp = 0;
    }

    else if (in == 'p') {
      analogWrite(pwmPins[channel], temp);
      temp = 0;
    }

  }

Question 2: Is this crash of Pd and the computer (macOS Mojave) expected behavior in a situation like this? If it is not, maybe it should be reported as a bug. It happens consistently.

Thoughts: Could there be a problem in [comport]? This crash behavior is identical with the problems I had when using Pdunio/Firmata.

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

EUREKA! I solved the following problem:

Problem: provide a mechanism for allowing patches to self-close without Pd crashing.
Requirements: (1) uses only Pd vanilla; (2) action to close patch starts on the very patch that will be closed.

Solution: copy patch killer.pd in the same folder as the patch to be closed, and send a message containing ";pd open killer.pd <dir>;kill_me symbol patch_to_be_closed.pd":

killer.pd
patch_to_be_closed.pd

Comments: (documented in the killer patch) Pd doesn't deal well with menuclose requests that originate (in a direct chain reaction) from the same patch that wants to be closed, so a separate killer patch is needed, which can be opened by the same patch requesting to be closed. In order to break the direct chain reaction, the solution is to postpone this request and make it appear as being originated inside the killer patch. This is done by storing the received symbol and delaying the message menuclose by 0 ms, which is enough to issue a new chain of events. The killer patch stays alive (but invisible), and any new instances of the killer patch will silently kill the previous instances so that only one killer patch is alive at any given time. [EDIT: I included a safeguard [pipe 1] in the killer patch, check the inline comments]. This implementation fixes the problems with my previous solution and also with the 3-patches method by @ingox, both of which didn't work through a send/receive pair. It also does not depend on dynamic patching.

This has been tested in Pd 0.50-2 and Ubuntu 20.04. I appreciate feedback to confirm if it works in other platforms/versions.

@whale-av Thanks again David for the suggestions (hcs, mouse clicks)! I wasn't too keen on the idea of depending on external libraries, and I also had to abandom the idea of having the killer patch embedded in the patch to be closed.

@Coalman A (log) sweep is best. And quite a slow one.
You need to give the room time to resonate and reveal its imperfections..... so an impulse or white noise are really a waste of time.
Low frequencies are complex in the room due to comb filtering...... you will need to measure at many locations in the listening area.
And first you need to plot the microphone against the sweep with the speaker outdoors to know the deficiencies of both the speaker and the microphone.

Test the room with the same single source first.... multiple sources will create interference patterns at all frequencies.
Plot the sweep level and the microphone level returned into two arrays and then subtract the sweep from the microphone at each index (outdoors)...... you now have a graph of the speaker to microphone errors at all frequencies.
Do the same indoors and you have the room errors combined with the speaker and microphone errors..... so now subtract the plot of speaker and microphone errors from that and you are left with just the room.

The main complication will be the latency.
If you send an impulse from Pd before the sweep you can manually offset each plot before doing the subtractions....... by setting an offset start for the microphone plot (offset by the number of samples before the impulse) when you play them back and produce the subtracted plot .

Probably an hour to build the patch.
Probably 12 hours to get all the plots.
Probably 12 days to fix the room.
Probably 12 weeks to get all your speakers in the best places and know exactly where to sit.
Probably 12 quadrillion zillion years before you will be happy.

I spent most of my life doing the same every day by ear (its a lot easier and quicker), outdoors, in railway carriages, clubs, Olympic gyms and stadiums.... with far more speakers and subs than could possibly be coherent.
120 Meyer 650 subs in the Albert Hall on one occasion.
Often we could move just one speaker by half a centimetre and all would come right.

I bought a house with a lounge with a 7 metre pitched ceiling..... 15 metres long....... 6 metres wide.
I put a pair of Quad ESL63's (point source concentric electrostatic speakers) and Gradient SW63 dipole subs in the right places........ and I am quite happy..... if I am listening to a great recording....... which is almost never........

Mono is underrated.
David.

Hi, I'm a complete Pd and audio engineering beginner trying to connect an electric guitar to my Macbook and process the signal to create some effects for a school project. I'm trying to use JACK for that purpose, but I searched the entire internet including this forum, and can't seem to figure out how to do it.

What I'm working with is:

• jack -> USB Behringer cable
• Pd 0.51.1
• JACK 1.9.16 installed with an installer from jackaudio.org and running the bundled Qjackctl
• macOS Catalina 10.15.6

When I run JACK in messages I can see that it recognizes the USB guitar interface C-Media USB Device:

In the connection graph I can only see these available:

Also while having JACK running, I go to MEDIA -> JACK in Pd and in the logs I get "Can't open Jack (it seems not to be installed)" error message.

I've also tried alternatives to JACK like Soundflowe or Blackhole, but don't understand how to use it to send the guitar signal to Pd or even how to send it to the speakers (is that even possible?).

My JACK settings look like this:

Any help would be greatly appreciated!

I get more and more problems: Error messages in the Pd window, stuck GUI (audio running but with errors), Pd crashes, Pd crashes the computer.

Now it is at a point where it is a real problem. At some stage I slow down working on a patch just because I fear it will break, and live of course it is a nightmare.

My impression is that the gui freezing happens more frequently while using large patches with many graph on parent objects. The error messages always writes out when opening or closing a (sub) window.

I try to stay vanilla but I have some external libraries loaded. I use the pduino lib with arduino unos connected over usb.

My main computer is a MacBookPro early 2011/16 gig ram, hybrid SSD/optical drive, OSX 10.13.6 High Sierra.

But the problems are similar on other macs I use: MacBookAir 2012 with Mojave and a MacBook 2009/8 gig, SSD, with High Sierra).

So, how should I go about to report this bug? So I can help in the best way possible? Should I post the patches where the problems occur in?

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

@whale-av The 3.5mm jack without a resistor would actually add more noise than with it,. The input jack is a switchting type jack, with nothing plugged in the tip and ring is shorted directly to ground, if you just plugged in a bare plug, it would break that short to ground, the plug would become an antenna and while being very short and limited in the wavelengths it could pickup, it would pickup a good deal and certainly more than the Johnson noise of a resistor, if you just plugged in a cable and left the other end unplugged, you would get even more since your antenna is now longer and can pick up longer wavelengths better. A resistor added in, will just resist, those weak RF signals will need to over come that resistance to reach the preamp and be amplified. Johnson noise is a very small factor, it does contribute, but it is not something one would really want to try and exploit as a noise source, a few feet of and wire will give you considerably more. A rather simplified explanation and not completely correct, consider it practical but not technical.

As an aside, the second ring on the standard tip, ring, ring 3.5 mm plug that we see on phones and anything that can take a headset is powered, those headsets use electret microphones which need some voltage to function. I am not sure what this voltage is, but if you can find a zener diode with a reverse breakdown voltage that is less than the voltage supplied by the jack for a microphone, you could likely build a noise generator into a standard 3.5mm plug with little issue. Zener diodes are generally thought of as poor noise generators, their output level is quite erratic, they are too random to be good noise, but that is great when your needs are random and not pure white noise. There is no real gain to building such a noise source into a plug, just plugging in any cable and leaving the other end floating will do just as well and with less effort.

@Jona said:

and you need Jack to route ALSA MIDI:

aconnect -l in any terminal will list all available software and hardware midi ports and then you can connect any of them by name or port number aconnect 'Pure Data:4' Blofeld or aconnect 128:4 28:0 will connect pd's midi out to my Blofeld and aconnect -x will disconnect everything or just one conenction if specified. Generally this sort of work is just handled by a script, so for me midiup will check what programs I have open and what hardware connected and figure out how they should be connected . For audio between applications we use the alsa loopback device to create a virtual soundcard to route the audio through using the alsaloop utility, with a script or through alsa configuration files. Alsa can do a great deal more than most think and often can do it better than Jack, Jack is just intuitive, alsa requires you to study up. The main drawback to alsa is that some applications have dropped alsa support, mainly DAWs, which is odd since they generally have no use for Jack since it is rare for a user to route audio between a DAW and another application, it is all internally connected in the DAW to the various plugins, everything is a plugin and Jack is often a redundant requirement that just consumes.

My setup is as simple as possible, midi controller to USB, alsa, pd, no jack. This problem has persisted through multiple pd versions and two different systems, the only commonalities between them are that both systems are source based and use old fashioned SysV. I have spent a fair amount of time in the past in both the alsa and pd IRC channels trouble shooting this and the best guess so far is that under certain circumstances pd does not clean up properly on shutdown and leaves alsa unable to make a proper midi connection into pd, midi out seems unaffected, aconnect -l shows the midi connection into pd hangs at 'connecting.' When this happens midi still works properly in all other applications, it is just pd and I have not been able to recreate the garbled midi in any other application.

Yes, [max], I have been learning [expr] lately and have become somewhat fixated on it, I often find myself using it for things which pd already offers a simple solution for, but I am getting better about that.

Edit; Forgot to mention, you can automate a great deal of the alsa connection, with the use of udev rules you can have the hardware to software connections made automaticaly when a device is plugged in and you can have a script that starts up all your programs and makes the connections between them, so one command or one click and everything is done for you. This works best for those that always use the same setup, but it can be worked to adapt to changing setups as well.