Beginner Question
@nenleh said:
In an tutorial I have seen that someone marked the checkbox "compute audio" in the main window of PD (first picture) to solve this poblem.
But I do not have this checkbox (second picture).
Ancient tutorial, then. The current "DSP" checkbox is the same as the old "compute audio" box.
What can be the problem?
The console messages that you get after clicking DSP say that it's an audio driver problem: Pd is trying to connect to an Advanced Linux Sound Architecture instance and this is failing.
Linux audio is famously messy. The current best attempt to clean up the mess is Pipewire, so I guess your best option may be to install Pipewire and run pd under its power. If it's me, I'd use the Media menu to choose the JACK backend and then run pd as "pw-jack /path/to/pd-gui" (I think; not at the computer right now, and the path may vary depending on Linux distro).
I have not yet used Pipewire, though, so I couldn't troubleshoot beyond that. Linux audio forums could help more. (Note that Linux audio being chaotic and disorganized isn't Pd's fault -- but once you get the audio subsystem configured, then it works for every app. It's painful only the first time.)
Also, "priority 6 scheduling failed" means that you should add your user to the "audio" group.
hjh
Having issues with audio preferences and PD freezing up
Hello all,
Running 'Pd-0.52-1-really' on a 2021 M1 Macbook Pro. When I need to change my audio preferences (namely my audio output device) in PD, I can select the output I need, but when I click 'Save All Settings' or 'Apply' the following happens:
- 'Audio off' switches to 'Audio on' in the main PD window (the DSP checkbox does not respond, it remains unchecked)
- PD freezes: clicking OK or cancel in the Audio Settings window yields no response, the window will not close via any means. Similarly, if I have a patch open this will also freeze and cannot be closed. I have found I can close the main PD window, but I cannot quit PD- I have to force quit via the finder.
Upon reopening PD it's a gamble as to whether the audio setting I changed has even been remembered. This is extremely frustrating and is rendering the software very unreliable and hard to use (especially as I use it almost exclusively for audio).
Also, if I skip the process of clicking 'Save All Settings' or 'Apply', and just hit 'OK', the audio settings window closes, but the program still freezes in the same way.
Additionally, I'm trying to open a patch that contains a load bang to start DSP, and this will also freeze the program.
Has anyone else experienced this, and can they suggest any solutions? Thanks!
Trying to add key switch functionality to a midi controller
@whale-av said:
@Alan-Angel You could be right about the order of operations......... https://forum.pdpatchrepo.info/topic/13320/welcome-to-the-forum
You need to store the right hand note so that it can be played later by hitting the left key.
I have broken it down into (I hope) an understandable work flow for a mono player....... this.pdSo that even if it doesn't work you should be able to understand the order of operations and fix the problems...
[pack f f] receives the velocity of high notes.... but that value is replaced by the velocity of the low note just before the low note triggers the playing of the high note.If you want to do this polyphonically you will need to use the [poly] object and to use the finished mono patch as an abstraction within a master patch containing [poly]...... probably using [clone].
That's slightly more complex.... but you will get there.....
David.
Thanks for your help. the low velocity isn't registering, I'll try to figure out why not but I get the logic.
@kosuke16 said:
Whale is right, my bad. I tried it only with the numbers, no audio so while the numbers where good, the timing wasn’t. Note message not being continuous, you have to repack it so it is send at the same time than the velocity to make a coherent list of two values for noteout.
Thanks for your help so far!
@ddw_music said:
My question about this:
Right hand first, then left hand: Note should be produced upon the left-hand note on.
- What if one right-hand note is pressed, and two or three left-hand keys? Multiple notes, or only the first? (Polyphony, I suppose, would have to be right-left, right-left, not the same as right-left-left.)
Left hand first, then right hand: Should it play the note upon receipt of the right hand note-on, with the left-hand velocity? Or not play anything? Or something else?
- And, if it should sound, what about left-right-right? Portamento? Ignore the second?
Because a full solution will be different depending on the answer to these questions. These need to be thought through anyway because you can't guarantee correct input -- the logic needs to handle sequences that are not ideal, too.
hjh
-
I don't plan on play two left hand notes, I just want to play fast galloping basslines like dun du-du dun du-du dun du-du dun and it'seasier to do with one hand and play the notes with the other, like a real bass.
-
Not sure about this one, I guess I'll know the more I play how I want it to work. Maybe default it to a low E like on a real bass for fun?
-
Agree, for now I just want some basic functionality to even see if the instruments I use can handle fast notes in the first place.
large array - how to visually update while writing? also how to pause+resume recording?
@esaruoho Updating the array while recording will probably cause dropouts. Redrawing onto the screen is hungry and unadvisable in Pd.
You can stop and start from the same point..... using a counter and restarting with a [start index(...... message, index being the next sample after where you stopped.
But.
Complicated.
It will probably be easier to stop audio computation when you press the [stop( button..... which will pause the writing to the array.
That will "freeze" audio for that window..... so you will no longer hear any audio that the window generates...... but other windows being unaffected you should be able to organise the patch to still hear what you need from elsewhere.
Put a [switch] object in the window with [tabwrite~] and toggle audio on off with a message..... 1 on.... 0 off.
Then connect [stop( to a 0 message and [resume( to a 1 message to [switch].
It will cause clicks, but you can stop that, while only losing a tiny bit of precision for the stop point, by "ducking" the audio before and after the [switch] operation like this.....
Use the [line~] output to duck the audio to [tabwrite~] so that there are no clicks on the recording as [switch] stops processing..... the audio recording level will be at 0 when processing stops and then fade up from 0 in 5ms when you start again (3ms after audio is turned on fully in the screenshot).
Set the [pipe] value lower if you wish..... 3 might be sufficient with 2 for the message to [line~].
The clicks might not matter at the stop/resume point of course....... and might make it easier to spot the "join" later.
David.
Pd on a Mac with Jack
@jameslo ALSA and OSS are low level/tied into the kernel. PipeWire, Jack and PulseAudio are more user level and communicate with ALSA or OSS. All of these have overlap but they are not quite the same thing. Essentially linux used OSS back in the day than OSS changed its licence so linux had to find something new in a hurry, enter ALSA which was not at all ready but pretty good, not as mature as OSS or as featureful but it did a good job within its limits, which is where Jack and Pulse come in. Jack and Pulse flesh out the features of ALSA but Pulse got adopted before it was ready and that first year or two was not fun and few seem to really like it, Jack is great when it works but can be a nightmare when it does not. Enter PipeWire which brings video into the mix and seems to solve many of the user/administration issues of the rest. Just fired up PipeWire for the first time ever and it seems to work quite well without issues but I have yet to give it a good test.
An application needs to be built with support for Jack, Pulse, ALSA and OSS if it wants to use them, PipeWire understands the languages of all of those and an app built with Jack or Pulse support will* work with PipeWire and unlike Pulse and Jack can also expose ALSA/OSS ports so applications can access them directly without the middle man which is one of the huge issues with Jack and Pulse, they both take over all available ports so no one else can get in. So now I am recompiling PD to see if it speaks to PipeWire through its Jack interface.
I know little to nothing about PortAudio, I believe it is a crossplatform library capable of talking to many different audio services.
*apparently you need to build the apps off of the PipeWire Jack libs and not the regular Jack libs which kind of sucks but nothing major, we don't have to wait for the devs to get around to fixing anything at least.
Pd on a Mac with Jack
Dummy check please. Is it true that:
- Jack can serve as audio loopback software between MacOS audio apps such as Pd
- Jack can run on an M2 processor
- The Qjackctl.app that is bundled with the Jack MacOS download runs on Monterrey without any additional runtime frameworks installed
- For Pd to send/receive from a Jack channel, Jack has to be running and you have to select Jack in the audio settings before you can select which particular Jack channel you want for input or output
- Soundflower is obsolete; Jack is current
?
Edit: I can confirm the 2nd through 4th bullet point but not the first and last. I've seen 2 tutorial videos on Mac audio loopback where you can see that the presenter has Soundflower installed in addition to whatever loopback software they were demonstrating, so that makes me scratch my head. RE that first point, I'm tentatively concluding that an audio app has to be Jack-aware (like Pd) in order for it to be routed by Jack, which isn't a requirement of other loopback drivers like Soundflower or Blackhole. Finally, it's worth noting that Jack doesn't come with an uninstaller, so to get rid of it you have to manually remove files from /usr/local and below, and the list of files can be found on one of the windows of the installation package if you scroll down. If that's not your cup of tea, don't install it!
TLDR: I'm not sure why anyone would want to use Jack on a Mac. Still happy to be schooled though.
Circular buffer issues
@jameslo said:
Honestly, I didn't know if that was @fintg's requirement,
It's certainly a reasonable guess. If the requirement instead were "I just played something cool; write the last 10 seconds to disk" you can do that without a circular buffer at all.
I was just surprised and annoyed that one can only access the delay line's internal buffer at audio rate (and was hoping that someone would prove me wrong).
Access to the internal buffer wouldn't be very useful without also knowing the record-head position. In that case delwrite~ would need an outlet for the current frame being written.
That would actually be a very nice feature request.
In SuperCollider as well, DelayN, DelayL and DelayC don't give you access to the internal buffer. But you can create your own buffer and write into it, with total control over phase, with BufWr -- and, because you control the write phase, you already know what it is. It's quite nice way to do it.
Basically the lack of ipoke~ in vanilla causes some headaches.
Look at the hoops I have to jump through! The extra memory I have to use!
I don't think there is any way to do this without using some extra memory.
In a circular buffer, you have:
|~~~~~~ new audio ~~~~~~|~~~~~~ old audio ~~~~~~|
^ record head
When you write to disk, naturally you want the old audio earlier in the file. There are only two ways to do that. One is to write the "old" chunk without closing the file, and append the "new" chunk, and then close the file.
In SC, if I know the record head position, I'd do it like:
buf.write(path, "wav", "int24", startFrame: recHead, leaveOpen: true, completionMessage: { |buf|
buf.writeMsg(path, "wav", "int24", numFrames: recHead, startFrame: 0, leaveOpen: false)
});
AFAICS Pd does not support this, so you're left with duplicating new after old data. (FWIW, though, there's plenty of memory in modern computers; I wouldn't lose sleep over this.)
Then there is the problem of synchronous vs asynchronous disk access. AFAICS Pd's disk access is synchronous, and because the control layer is triggered from the audio loop, slow disk access could cause audio dropouts. OS file system caching might reduce the risk of that, but you never know. Ross Bencina's article about real-time audio performance advises against time-unbounded operations in the audio thread.
SC's buffer read/write commands run in a lower priority thread; wrt audio, they are asynchronous. This is good for audio stability, but it means that, by the time you get around to writing, the record head has moved forward. So, even though I could do the two-part write easily, I'd get a few ms of new data at the start of the file. I think I would solve that by allocating an extra, say, 2 seconds and then just don't write the 2 seconds after the sampled-held recHead value: startFrame: recHead + (s.sampleRate * 2)
. (If it takes 2 seconds to write a 10 second audio file, then you have bigger problems than circular buffers.) Then the record head can move freely into that zone without affecting audio written to disk.
hjh
Failed to autostart PD on Pi using service
This is a continuation to the issue I wanted to solved in this topic. It just went to different places so I though I will open a new topic to this problem I'm facing.
I have a pd patch that doing some audio playback reading some files from buffer. I'm running it on my Pi4.
I wanted it to start on boot every time and to be able to reset itself if crashing for some reason.
I was suggested to use that service script:
[Unit]
Description=My PureData service
[Service]
Type=simple
LimitNOFILE=1000000
ExecStart=/usr/bin/puredata -nogui -open /home/pi/mypatch.pd
WorkingDirectory=/home/pi
User=pi
Group=pi
Restart=always
# Restart service after 10 seconds if service crashes
RestartSec=10
[Install]
WantedBy=multi-user.target
The above was working great using the built in 3.5mm audio jack.
I then bought UGREEN USB audio interface as I was facing with some poor audio quality at the output.
I set the audio preference in PD to choose the USB Audio Interface as the output.
When I boot the Pi I'm getting this error from the service (see picture)
If I'm typing sudo systemctl restart my_puredata.service
the PD patch is back to work just fine. No Alsa error, but on the initial boot it is not working.
Any idea why this happen when using the USB AudioInterface? anything I can do in order to make it work?
So If to conclude:
When I start the same pd patch using the same service script but without a USB audio interface is working just fine.
When I start the same pd patch with the USB audio interface but using the autostart file:
sudo nano /etc/xdg/lxsession/LXDE-pi/autostart
Is also working just fine.
But the combination of the USB audio interface and the service script is just not working.
Thanks for any help.
No sound. Failed install?
@mario60 PulseAudio is hogging alsa. Supposedly you can use pd with pulse audio through the portaudio backend but it has never worked for me. You have a few other options as well, you can install jack recompile pd with jack support, this requires you to run pulse into jack, or jack into pulse, or suspend pulse when you start jack. Or you can suspend pulse and use alsa direct. Portaudio->PulseAudio can be troublesome with audio, Pulse has a fair amount of latency so if you want to process live sound it generally is not a viable option, but if you just want to patch together synths in pd than it should be fine.
Jack is the most reliable and the frontends for jack have provisions to handle the pulse stuff for you, but you will probably need to do some setup the first time around on a system like Fedora which does not seem all that popular in the audio community. Initial setup can be a pain but once it is going you just start jack and that is it. Suspending pulse manually and using alsa works well but there can be surprises when restarting pulse, and they can be a trick to sort out.
Raspberry Pi Bluetooth Speaker not showing up in Audio preferences
@eulphean said:
I'm using pure data on a raspberry pi 3+ for a project. I have bluetooth configured properly on it. I can send regular audio to bluetooth speaker connected, but the preferences -> audio in PureData doesn't show the bluetooth speaker. It only shows internal audio card or if I have a USB audio card, that shows too. But no bluetooth device.
How do I configure that? Do I need to use jack or something to route audio to bluetooth for Pd?
My experience with Bluetooth audio in Linux has been:
-
JACK has zero tolerance for the audio driver ever being late -- expect crashes or system lockups if you try to route audio from JACK to Bluetooth. That is, just don't.
-
PulseAudio's support for BT audio is pretty good -- the "regular audio" that you spoke of. Audio production apps typically bypass PulseAudio, in which case BT audio may simply not be supported for them. That is, I expect you'd hit the same problem with SuperCollider, Audacity, Ardour, VCV Rack etc etc etc.
I'm not aware of a solution... That's not to say that there absolutely isn't one, but the Linux audio space is not unified as it is in Mac so audio device support may not be universal.
hjh