• jameslo

    @cfry You don't need any externals. Here's something I used to understand how QLab sends and receives OSC:
    Screenshot 2022-01-22 142334.png
    The output of [oscparse] is just a list that contains the OSC path plus whatever data at the end which you can process as you would any Pd list.

    posted in technical issues read more
  • jameslo

    @whale-av Nah, if I run Pd as administrator I get the same error (administrator is granted debug privileges by default on my machine).

    I still miss Windows 7. Nothing gold can stay.

    posted in technical issues read more
  • jameslo

    @whale-av In the test you're proposing, where would [trace] be inserted?

    I think I described the issue too tersely. The trace output in the console window is fine, but I'm talking about the feature where you can control click on any of the trace lines and it selects the object that caused it. Any trace line I ctrl-click results in "... sorry, I couldn't find the source of that error." being output in the console window, and nothing is selected.

    Update: On MacOS 10.14.6, when I command-click on a trace line, the corresponding object is selected and the containing window is put into edit mode. That's what I was expecting.

    posted in technical issues read more
  • jameslo

    Has anyone gotten the ctrl-click feature of [trace] to work on Windows 10? I get the same apology no matter what I ctrl-click.

    Screenshot 2022-01-08 102124.png

    posted in technical issues read more
  • jameslo

    Agreed. I've been playing with Camomile and have written effects plug-ins in Pd that have sent and received MIDI and/or OSC and have been controlled by DAW automation, so that's substantial integration. I defer to @emviveros regarding the support for externals since I'm just a vanilla guy. I've also written effects plug-ins with side-chains for Reaper, so that means your Pd VST patches can be modulated by audio signals from other Reaper tracks. Reaper itself supports fairly complete OSC and MIDI controls (both input and output) so that's another layer of integration that's possible. And for completeness I suppose one should mention using MIDI and audio loopback software, but the flexible MIDI and audio routing capabilities in Reaper seem to make them unnecessary.

    posted in tutorials read more
  • jameslo

    @lacuna said:

    anyone ported this to Pd yet?

    @solipp's pp.fft-split~ in Audiolab might be close enough for @schitz's purpose

    posted in technical issues read more
  • jameslo

    @raynovich Here's an alternative to soundfiler that spreads the file loading over several audio ticks. I don't think you can resize the array without there being hiccups though. soundfiler alternative.pd

    soundfiler alternative.png

    posted in technical issues read more
  • jameslo

    @ddw_music Oh, ha ha, I thought you had already pointed out the ridiculousness of my suggestion by framing OOP as message passing, i.e. "Oh, so you're asking me to treat the Pd message as the object, and the Pd object as the message being passed to the Pd message asking it to transform itself? Hey, thanks a lot, that clarifies everything!" I was already laughing.

    In my (very weak) defense I was mostly thinking about order. first.concat(last). a.append(b). But I was also thinking about the append method of an object. I learned OOP not as message passing (e.g. Smalltalk) but as encapsulation. Some early non-OOP languages (I can't remember, so long ago...Pascal?) had facilities to group data together with the functions that accessed/modified them within some scope, and unless you had access to that scope, then you couldn't just go do whatever you wished with the data. Honestly, I used to try to do that in assembly language, though admittedly there was no encapsulation enforcement--it was just about hiding all the nasty details in a single compilation unit. So if I were to come across the append method of a list object, I would assume that the list was thing that was being modified and that the argument was the...uh...argument to the modifier.

    Remember that [list] and [list append] are synonyms. Are you convinced yet? :)

    That said, I'm never shocked whenever someone tells me that my intuition is weird. I think you're better served by @ingox's and @oid's suggestions, which are unforgettable IMHO. Unless you're too young to know who Queen is, in which case you substitute...uh...I dunno...Lil Nas X lyrics?

    posted in tutorials read more
  • jameslo

    @seb-harmonik.ar Why is interest in double-precision floats so weak? All the discussion/documentation of it I've found is very old.

    posted in technical issues read more
  • jameslo

    I made a trippy oscilloscope graphics patch that does its thing when driven by a sweeping sine wave and was hoping to sweep from 0 to 22050 hz at variable rates in order to pass more quickly over the boring parts. So I thought I'd just accumulate the frequency signal using rpole~ and vary the left inlet (i.e. the increment for each sample period). Well the whole patch froze when the frequency reached 256, and I thought it must be due to trying to add such a small increment (10 millionths) to a relatively large number 256 (large in single precision floating point terms). Not the dumbest conclusion to jump to, right? There are about 8 decimal digits between the increment and the max value.

    So I remember reading about "onset" in the tabread4~ help file, and thought maybe I could do something similar. Problem is that it's not behaving as expected. As you can see in my test patch, when the next onset is snapshotted, the slope changes. I turned off DSP after the left rpole~ maxed out at 256, when the right one had only gotten to 254.5! I can't explain that at all, except to suspect that it has something to do with the boundaries of single precision floating point that I don't understand. So I've provisionally decided that there's no way to write a Pd vanilla patch to do what tabread4~ does with onset because no matter what you do, you're stuck with single precision floating point arithmetic. Agree?
    rpole~ and single precision float.pd
    rpole~ and single precision float.png

    PS: line~ has similar issues. Try slewing from 256 to 257 over a minute and see what it does. A total head-scratcher.
    line~ weirdness.pd
    Update: it works better if you slew [line~] from 0 to 1 over a minute and add 256.

    posted in technical issues read more

Internal error.

Oops! Looks like something went wrong!