-
Load074
OK... one crash-during-performance later, I'm looking more closely into this.
If I have the USB device set to "Output Device" as well as "Input Device," and unplug it while PD is running, PD will crash. If, however, the device is only "Input Device" and not an "Output Device," unplugging it is no problem.
Also, if I have PD set to "MIDI Through-Port [0,1,2,3...]" (instead of looking directly to the device) and make the nanoKONTROL2 -> MIDI Through-Port in, ie, qjackctl, then I can unplug without a crash.
So! Maybe I should file a bug report? Or maybe someone else who has an input + output USB MIDI device and is running PD on Linux (or, who knows? any platform?) wants to try this out and see if it's just me?
-
Load074
Hear, hear. I've been getting into the habit of (trying to) ALWAYS use [t whatever whatever], even when it seem unimportant. Too many times have I been bitten by a seemingly-innocent execution order (egad that sounds sinister) from the earliest experimental stages of whatever patch I've been building.
-
Load074
@oid thanks for checking your system. It's probably an Arch-thing or, more likely, a me-thing then.
I haven't changed anything about my setup, and I've used this Arch & PD installation for at least two years now. I use Jack for audio and MIDI, and usually use PD itself to make the connections (although to be honest - and this is a question I've had for ages now - I'm confused about PD MIDI connections / ALSA MIDI / Jack MIDI, and how sometimes I can make all choices in PD, and sometimes (depending on the PD version?) I have to use Jack).
-
Load074
This is new, I believe. At least, I've never encountered it before, and I'm sure I've hot-swapped in the past.
So: in PD 0.54.1, if I unplug the USB MIDI device (ie, tested both Korg nanoKontrol2 and nanoPad2), PD just up and quits. I don't need to be monitoring anything (like with [ctlin]) though the device needs to be one of my input/output devices.
I'm running up-to-date Arch Linux, kernel 6.7.1. Anyone else? Just me? Bug report, or is there a bug in my brain?
-
Load074
@beep-beep Hot dog - your comment actually pointed me towards something that works good enough for me!
Using [abs] will at least keep everything positive, so the discontinuities aren't crossing the zero line... and then, to make it even prettier, I inverted it with [* -1] to make a mirror image.
Since this is just for looks, I think it'll be good enough... it may turn out that I need a smaller viewer (less than 2000 points) even still, but so far, no glitches, and it looks reasonably like the 7-minute file I loaded.
/home/scuttlebutt/Pictures/Screenshot_2024-01-23_21-42-53.png -
Load074
Thanks - it's good to know, at least, that it isn't just a simple obvious object I was overlooking. And thanks, @nau, I'll take a look at those libraries when I get home!
-
Load074
It's SO satisfying to have a little [hslider] moving along under an [array] which shows the waveform... maybe you can even grab the [hslider] and drag it to a new point in the file/sample...
But they're SO BIG! Any long sample is made of of many points, even if the display is shrunk down. That makes my PD hiccup whenever it needs to redraw the waveform (ie, minimize then maximize the window).
I've tried making a duplicate of the real [array], but forcing it to be "lower resolution" (say, 1000 points). Sadly, sampling every "arraySize / 1000" points and writing that to the arrayView doesn't look anything like the original. Neither does averaging all the samples within a given chunk... though it DOES take a long time!
Is there another, easier, more commonplace solution I'm overlooking?
-
Load074
wait wait wait... are you telling me I don't have to use [this( and [next( !?!?! How else does one do it? Oh... can I keep a counter in my main patch, and send messages to successive [clone] 's? So then I'd know I was on #47, and I'd send all my details to #47... is that how that works?
Brilliant.
Hold on, I'll be back in a few hours....
-
Load074
not to get all High School Yearbook, but... "sorry so sloppy."
The cloned part is "changeGrain." My front-end patch has four of the "quadSamp," each one of them relating to a specific sample. They get triggered quickly (as fast as 5 ms), so there can be a time where four different samples are triggered within 5ms of each other.
quadSamp is also where I can set, ie, the rate or the filter to be different for Sample A than for Sample B.
quadSamp:
quadSamp.pdAnd so the problem is that, for instance, Sample A is Duran Duran's "Fame" but filtered and slowed down - no problem - but when I occasionally trigger Sample B (David Bowie's "Fame") I hear bits of Sample A at normal speed and unfiltered (following Bowie's parameters).
changeGrain (that which is cloned):
changeGrain~.pd
This might not make sense, and my patches might be too personal/messy for anyone to want to take a look... -
Load074
Trying to fully fathom [clone]...
I am working on a granulator patch which uses many [clone]s, and four possible samples to choose from/mix between (ie, 25% chance of grain A, 75% chance of grain B ). I think Carl Stone might already do something like this, but he uses Max, so, totally different.
Anyway. I'm using a [t b b b b...] to, first, a [next newName $1( to choose the sample, then a bunch of [this rate $1(, where the "THIS" messages are attributes (rate, filter, whatever).
When I'm mixing my grains (ie, anything other than 100% of grain A), the "THIS" attributes sometimes get applied to the wrong sample. That is, if I know grain A should be slow and heavily filtered, and grain B is fast and bright, I hear some A's fast and bright.
I thought using a [t b b b b] would ensure that the the same sample chosen by [next( would receive all of the appropriate [this( but... no?
-
-
Load074
Is it just me? I haven't heard noises about this yet. But I couldn't open lots of my patches in the newest PD last night. Some small ones were OK, but any larger ones (with Graph-On-Parent? Colors?) crashed PD instantly with a Core Dump.
Anyway, I rolled back to PD 52 and all was well. Didn't do more research into the cause; rolling back quelled my curiosity. Just mentioning this for future generations.
-
Load074
Thanks David - I'll start trying this troubleshooting/tracing method. When this happened last, I believe it was freezing regardless of which windows were open. I should try again with everything minimized... but it's tricky, cuz it takes a long time (an hour?) for the freezing to commence.
-
Load074
I have a humongous patch that I won't share (it's too big and complicated and messy and undocumented to mean anything). Last night I was running it for an hour or so (two versions, actually, but all my variables are with $0- so they can go simultaneously) and it eventually reached a point where it would just stop all computation for up to twenty(?) seconds. All audio, all GUI, everything froze. Not my computer, though, definitely just PD. "Audio Error" (or whatever shows up next to the DSP on the main window) would turn red when this would happen.
I'm running Linux, and I was not getting any XRuns (which is another hint that it's just PD that's bogging down, not my whole system).
I know this isn't a lot to go on, but have people seen this before? I have some theories: I have large tables being written to, but even if I close them (to ease up on the GUI), it continues to happen. Another thought - I have lots of counters... a long time ago, I tried to put in some checks where, if they got over a certain range, I'd set them back to zero. If I missed some, could that cause PD to freeze? If I was using a simple counter and it got into the millions/billions? Hmm, a billion milliseconds is almost twelve days...
-
Load074
Thanks @oid and @whale-av. I had actually made a similar (but uglier) version of NRPN before I knew about NRPN; some weird powers-of-10 stuff that didn't exactly make for smooth transitions... but it is something to think about. What I'd really like, though, is something where I simply have better than 128 points of distinction on a single controller... especially if I'm, say, scrubbing through a sample - if it's very long at all, it becomes obvious that I can't get halfway between two points. A two-controller method works, but isn't as faux-analog'ly satisfying as being able to nuance a single pot (like I love to do with my guitar pedals).
So I'll probably stick with relative mode and PD-side math (which I've also done before). I was just dreaming that there was some good, potentially non-MIDI hardware interface/protocol that I didn't know about! -
Load074
Hope no one minds that I'm just jumping on to this month-old conversation... but I have some similar questions.
I was going to ask if anyone has ideas for better-than-128 resolution controllers (ie, not MIDI. HID? MIDI 2.0?). But looking at what @oid said, maybe my best bet is to settle on rotary encoders (giving up on sliders) and use "relative" mode to do the math in PD.
Is that the general consensus? All my ancient nanoKontrols are getting futzy anyway, it's time to upgrade...
-
Load074
@alexandros yes that was very easy indeed. Downloading the source files from https://puredata.info/downloads/pure-data installed with none of the predicted dependency problems on my old-as-the-hills (but up-to-date) Raspberry Pi. In fact, if I'd bothered to read all of the INSTALL.txt before I started, it would have been a success-on-the-first-try endeavor!
So now I have 0.52-1 and a [delete(-able [list-store].
-
Load074
Thanks @alexandros and @dfkettle I might try something like that. I have a suspicion that there will be some core libraries I'd need which might be beyond my Linux skills to update without a total dependency mess, but I'll see...
@whale-av, yes that is a great library! I hadn't explored it before, thanks for the tip. Unfortunately, the way my patch was built, [list-delete] is very far from a drop-in solution, and descending into the fifth circle of Raspberry Pi Dependency Hell may still be the pleasanter option.
-
Load074
Oh, I see... I was using [list-store] messages that are new to PD 0.52. I just tried on PD 0.51.3, and I get the same error. So it's not the Pi.
Guess I need to find another way to easily remove one element from a list!