Feature/multichannel

[ben-wes]

First attempt to close #53 that might cover all requirements.

Attaching some test files here once more:
test-lua-mc.zip

Brief documentation:

• Lua dsp function passes inlet channel counts with additional table:

  function myobj:dsp(samplerate, blocksize, inchans)

• signal_setmultiout is exposed and can be used to set outlet channel counts in dsp function. example for setting 1st outlet to 2 channels:

  self:signal_setmultiout(1, 2)

• samples of additional channels are concatenated to samples of first channel for iolets. this would be one way to switch channel 1 and 2:

  function myobj:perform(in1)
    out1 = {}
    for i = 1, self.blocksize do
      out1[i] = in1[i + self.blocksize]
      out1[i + self.blocksize] = in1[i]
    end
    return out1
  end

• PD_MULTICHANNEL can be set to 0 to build without multichannel support (automatically gets set depending on Pd src otherwise)

EDIT: successfully tested:

• macos arm64
• windows amd64

[ben-wes]

reverted a few formatting changes now to minimize the changeset.

[agraef]

Are all the other design questions resolved now? Or did they just disappear because you force-pushed them away?

Sorry, seems that I'm a bit late so that you had to decide these issues yourself, but as I said I was busy with other things today...

[ben-wes]

Are all the other design questions resolved now? Or did they just disappear because you force-pushed them away?

they are resolved imho, yes. i commented on them all here if you want to check the reasoning. i actually did that with additional commits instead of force-pushes so that the changes are visible.

Sorry, seems that I'm a bit late so that you had to decide these issues yourself, but as I said I was busy with other things today...

no problem at all! i'm sorry if all my changes and comments put pressure on you - that was not the intention! that stuff was just very present in my thoughts and whenever i had some idea, i checked the code myself once more and gave it a try.

[agraef]

Ok, after reviewing the code I'm getting ready to merge this. Do you have a patch demonstrating the feature to go along with it? Something that looks a bit less scary than your test patch. ;-) This should go into pdlua/examples. Maybe a multichannel version of osci3d? (But please keep the old one for people still running old Pd versions without mc support.)

Also, can you still please write something about multi-channel in doc/graphics.txt and pdlua-help.pd / pd graphics? I will then take care of the tutorial (probably I'll be my usual lazy self and just add another callout pointing to your docs and example; we should really add something more substantial there, but that can wait until we have some really nice example).

Awesome! Even awesomer is that I didn't have to write a single LOC myself!

Congrats on your first "real" code contribution! 🥇 (Note to self: change README and website.) Now this was substantial, but I hope that it wasn't quite as difficult as you expected, was it? When we meet next year, I really owe you a couple of beers now. :)

[agraef]

Just compiled and ran it on Linux with purr-data, works without a hitch. If you're too exhausted to do the doc and example after this ordeal, that's ok, I can do it myself later today. 😅

[ben-wes]

Ok, after reviewing the code I'm getting ready to merge this. Do you have a patch demonstrating the feature to go along with it? Something that looks a bit less scary than your test patch. ;-) This should go into pdlua/examples. Maybe a multichannel version of osci3d? (But please keep the old one for people still running old Pd versions without mc support.)

a multichannel version of osci3d sounds right - will do! for the simplest (?) lua mc object, this might do:

local test = pd.Class:new():register("test~")

function test:initialize(sel, atoms)
  self.inlets = {SIGNAL}
  self.outlets = {SIGNAL}
  return true
end

function test:dsp(samplerate, blocksize, inchans)
  pd.post(string.format("samplerate: %d, block size: %d, input channels: %s",
    samplerate, blocksize, inchans[1]))
  self.blocksize = blocksize
  self:signal_setmultiout(1, 2)
end

function test:perform(in1)
  out1 = {}
  for i = 1, self.blocksize do
    out1[i] = in1[i + self.blocksize]
    out1[i + self.blocksize] = in1[i]
  end
  return out1
end

Also, can you still please write something about multi-channel in doc/graphics.txt and pdlua-help.pd / pd graphics?

sure! 9ed55f1

Congrats on your first "real" code contribution! 🥇

thanks! 🎉 ... hope it will prove stable in the future, too. :)

Now this was substantial, but I hope that it wasn't quite as difficult as you expected, was it?

it was only possible with the help of all the existing code. but yeah - in the end, it looks surprisingly simple.

When we meet next year, I really owe you a couple of beers now. :)

haha, i'm in!

[ben-wes]

just quickly adding: the changes for an osci3d_mc~ (whatever we call it) are obviously simple (reading x, y, z from the first inlet) - but i'll unfortunately have to do that later tonight after earning a living.

one thought i had on this: we might give users some option to check for multichannel support already in the initialize function to handle iolet management based on this. but it'll add more complexity and maybe we also don't need this level of backwards compatibility.

[agraef]

Yeah, let's keep it simple. Users should be able to understand that they need multi-channel support to run a multi-channel Lua object. Same as with any kind of multi-channel external. You might add a caveat to your help patch, saying: ⚠️ "Grandpa, this is a MULTI-CHANNEL object, don't try to run this on your old and trusted Pd 0.32, it won't work!" They'll also notice that something is afoot if those snake~ objects won't instantiate. :)

Here's something I quickly cobbled together from your minimal test~ object from above. I think that'll do for now, so you can take your time with your mc examples.

[agraef]

Ok Ben, I take it that you're done testing in vanilla, and I did my own testing in purr-data, so I'm going to merge this now, and add the example I made. @timothyschoen You may want to give this a whirl yourself. I don't see why it should break in plugdata and libpd, except maybe for the dlsym hack used to detect whether the host supports multi-channel -- in that case we might have to add an #ifdef PLUGDATA or something similar to bypass that check at pdlua.c L3036 and just set the function pointer to the actual signal_setmultiout function.

[agraef]

Well, as usual the patch looks rather crappy in vanilla, and the output~ abstraction there doesn't have any outputs so I had to rearrange things a bit. But anyway, here's that multichannel test patch again, now running in vanilla:

[agraef]

Compare with this, then you might understand why I love purr-data so much:

[ben-wes]

I quickly cobbled together from your minimal test~ object from above.

cool! just to go sure: in your example, i don't immediately see that test~ flips L<->R. obviously, it still does illustrate very well the multichannel input/output!

as usual the patch looks rather crappy in vanilla

yeah ... crispy antialiasing-free! ;) ... luckily this is not an issue on macOS though.

[agraef]

i don't immediately see that test~ flips L<->R

Yes, it's hard to see, but you can hear it, especially when toying around with the parameters in the expr object.

yeah ... crispy antialiasing-free! ;) ... luckily this is not an issue on macOS though.

Pd in macOS is ... tolerable, I'd say, but on Linux and Windows I just can't run vanilla for more than a few (low single digit) minutes or my eyes will start bleeding. (Quite literally-- my eyesight is not the best anymore, and those gui fonts are much too small for modern high-dpi displays, while the patch zoom has only two levels: too small and too large.) The vanilla devs really need to get their act together and throw out that Tcl/Tk GUI. It looks like something from the 1990s (which it is). Reminds me of Motif / Common Desktop Environment (CDE) which looked great at the time (at least compared to Athena), but not today. I still remember those days. :)

[agraef]

Just for the record, and for testing purposes, here's that multichannel test patch: multichannel.zip

[ben-wes]

those gui fonts are much too small for modern high-dpi displays, while the patch zoom has only two levels: too small and too large

i don't remember what i did there exactly - but when i was still on windows, i somehow managed to have an acceptable setup through display zoom settings etc. but sure - free zoom levels are great.

The vanilla devs really need to get their act together and throw out that Tcl/Tk GUI. It looks like something from the 1990s (which it is).

i think there are some developments going on in that direction (starting a while ago and in the last days/weeks) and i'd be more than happy to see a different gui there as well! - mainly for performance reasons though. i admit that i still keep coming back to vanilla all the time for its visual simplicity. although design-wise, there are certainly some options to make patches more readable - and it's totally lacking a dark mode.

[ben-wes]

oha! merged! thank you so much for all the feedback and support here!

[agraef]

I only had to press a button 😉 -- all kudos to you! Feel free to follow up with another PR when osci3d-wc is finished, or if you have anything else to add. Tim, the same goes for you if you discover any plugdata incompatibilities.

I'm currently working on adding that multi-channel note callout to the tutorial. After that, I think I'm just going to release 0.12.20 so that we get this out in the wild and people can start to test it.

[agraef]

and it's totally lacking a dark mode

Yeah, this is getting OT, but who cares... While we don't really have full gui themes like plugdata has (apart from the theming for Chromium which the OS desktop provides), there are canvas gui themes in purr-data. Here's "Inverted" in purr-data:

We also have a bunch of other, more colorful themes, including one for C64 fans. And for vanilla aficionados there is a theme as well (also an inverted version if you prefer dark mode):

But of course if you want a vanilla version with a dark mode, you can just use plugdata if you don't need all of purr-data's external libraries.

I don't really like to work in dark mode, so I usually prefer a light theme, and I think that purr-data's default theme actually looks pretty good and is easy on my aging eyes.

[agraef]

Ben, as soon as you're done with earning your "Brötchen", can you please start work on updating the workflow so that it builds against a newer version of Pd (currently it's using Pd 0.52 on Linux, thus of course the mc support doesn't work there, even in the Pd 0.55-1 which I'm running here).

It's a good test that shows that your mc support magic actually works, but in this case I'd rather have a different result. 🤣

[ben-wes]

as you're done with earning your "Brötchen", can you please start work on updating the workflow so that it builds against a newer version of Pd

weird - i have no idea about the mechanisms there, but obviously sudo apt install puredata-dev is not a good idea if the pd version didn't get updates anymore.

so before the Brötchen are done, i patched this with the github frontend here (and of course made a stupid mistake there first). but can you check these ubuntu builds here? https://github.com/ben-wes/pd-lua/actions/runs/11253875795

if they work, you could merge my master branch (and possibly squash these 2 commits into one).

[agraef]

Got it, thanks for the quick fix!

[agraef]

Works like a charm now. Committed, pushed, and force-pushed the tag to update the release.

[agraef]

weird - i have no idea about the mechanisms there, but obviously sudo apt install puredata-dev is not a good idea if the pd version didn't get updates anymore.

I think that Ubuntu 24.04 LTS hasn't been rolled out on GH yet, so we're still using Ubuntu 22.04 LTS at this point. At least that's what I see in the build logs. And Pd 0.52-1 is the Pd version on 22.04, end of story. If you want something newer, tough luck, you need to upgrade the entire freaking OS. Even Debian stable, much ridiculed for the glacial speed at which it moves, has the most recent Pd version in the backports (probably thanks to IOhannes' work who maintains Pd and a bunch of other multimedia packages in Debian).

That's why I run a rolling distro on my own computers, and do most of my purr-data Linux packages on the OBS. The SUSE people do a really great job providing you with up-to-date runners for a bunch of different Linux systems. GH has always been lagging behind quite a bit with their runners.