Loris partial data manipulation in SuperCollider

Questions
1

Dear SC community,

Has anyone here attempted to manipulate Loris (https://www.cerlsoundgroup.org/Loris/) partial maps in SuperCollider? I’m interested in real-time exploration and transformation of bandwidth-enhanced partial tracks, to sketch variations of sounds I will analyze with Loris. I know working with Loris data is easily doable in Csound with beadsynt – which was actually based on a Supercollider synth with the same name, although I couldn’t find any info about that –, but I’m specifically looking for approaches within SuperCollider since it’s quicker for me - whether through direct integration, data conversion, or whatever you suggest.

Would be amazing if a more experienced user could chime in.

Thanks a lot, hope you all are having a creative start to the year :slight_smile:

2

I think the best thing to do is probably use the API and extend it to SC. There’s also the possibility of running SC alongside Loris from the command line or running both from VSCode but I don’t know how well that may or may not work…

There are other spectral tools in SC, but they’re not the same as Loris. I’d point you toward FluCoMa for spectral analysis/resynthesis specifically inside of SC, but it’s not the same thing

3

Yup. I have Loris UGens and classes. Can share if you like!

5 Likes
4

I would also be interested in this!

5

I’ll share! Do people use MacOS or otherwise? I’ve never built for Windows and Linux, and I’d have to check if the Mac binaries are code-signed/notarised…

Sorry, there used to be binaries of these available. I think it got a bit confused. I wanted to add the whole bunch (BEASTmulch UGens) to sc3-plugins but the feeling at the time was too much additional ‘technical debt’ IIRC. The situation was messy as someone took the VBAP plugins from the same project and added them to sc3-plugins without discussing it with me, which meant there were differing versions kicking around, and I just never got around to cleaning everything up. Will sort something out, but may take a few days.

4 Likes
7

oioi,

sorry for replying a bit late. sounds like you have the perfect solution! i can volunteer to beta-test the refactored UGens before you release them into the wild, if you want :slight_smile: i’m on a M1 machine so MacOS binaries is all i personally care for, honestly. and i could just force the codesigning myself; i wouldn’t worry about notarisation. it’s easily done by the user.

thanks for chiming in!

EDIT: i found a link to the BEASTmulch UGens you mentioned. is this bundle the one you were planning to share? here’s the project’s official page for those interested.

8

Yes, you can try that, though I think it’s quite old!

1 Like
9

Here’s the current build on my machine (Mac Intel): You’re welcome to try.

1 Like
10

I’ve moved the repo to GitHub: GitHub - muellmusik/BEASTmulch-plugins

Let me know how people get on with it. It’s probably a bit messy in its current state. Sorry! :slight_smile:

Happy people are interested. I’ve done a lot of fancier manipulations than are in the help files. Can share discuss if people like.

1 Like
11

thanks for the links and the share. i would love a glimpse into the fancier manipulations you are referring to. whatever helps get the juices flowing, i’m in.

i’ll also attempt to build the native ugens for apple silicon macs if the currently available binaries don’t work here. in any case, i’ll report back here soon with my experience!

12

these didn’t work in my system (m1 max running on sequoia), but seems like i successfully managed to build arm versions from the source. if anyone else’s interested, i can share the files here, but let me first give it a test drive :smiley:

2 Likes