App - The Party Van

[rknLA]

Cool. I’ve give that a cmd+F when I get there.

And in case you’re curious to hear how it’s sounding, Latest tracks + videos

[rknLA]

Ah wow, so everything really is happening in mono!

I think I’m going to wait until you’ve got a proper 1.0 (or possibly just wait until TPV 2.0 is out?) so that I don’t create more work for myself trying to merge my changes into newer versions.

More brainstorming and notetaking in the meantime

[Rodrigo]

Yup, mono as fuck!

I might do another beta once I’ve finished the UI revamp stuff. I also noticed today that the newer version of the mubu library breaks Combine (I hate dependencies…), so I need to fix some other stuff there too.

What kind of changes are you making? I could upload my working copy if you want a more recent fork from it (though as mentioned, Combine isn’t working).

I’ve also decided I’m going to incorporate a phase vocoder into the grain module, and probably rename it SMEAR (or something like that. open to suggestions), since it will do either time-based (grain) or frequency-based (pvoc) extension and speed/pitch decoupling.

[beo]

I’m going to incorporate a phase vocoder into the grain module

excellent

why SMEAR ? (edit : or does it mean something ?)

[Rodrigo]

Nothing specific, but just a general purpose temporal displacement thing, like smearing it in time. Grain quite specifically means granular synthesis. I could keep the name and just have a time/frequency toggle.

[beo]

ah ok
(funny, with capitals i thought i was an acronym)

[Rodrigo]

Heh yeah, I can see that. I just did that since all the UI elements are caps now.

[rknLA]

I managed to get a working single-row of BP running in Live last night, just before bed. I’ll be testing it with the full 8 rows either this evening or tomorrow morning, and then posting a copy after making sure it works.

One part that I had questions about: In order to modularize the monomeControl and fingeringParser patches, I had to change a whole bunch of sprintf objects in various subpatches of the fingeringParser. Instead of using #1-style arguments for the row number, I’m grabbing the Track number from the Live Object Model to generate the row argument, and I’m using --- as send and receive prefixes to make them device-specific. The sprintf objects were coded to use %ld, but using --- as an argument winds up rendering as a symbol (even though it generates an int… ¯\_(ツ)_/¯), so I had to change the sprintf statements to use %s to render the symbols instead of %ld, which choked when the argument wasn’t an int.

A quick test seems to show that the %s version works with ints as well, so I wonder if it would be reasonable to propagate this change to the main Block Party implementation? There’d still be a bunch of find-and-replace work to switch all of the #1 values to --- to port new updates, but using %s will make the monkey patching around gestures easier

[Rodrigo]

Sweet!

Do you mean the stuff like sprintf send %ldkarma_pitch_transpose? That could just broken up too, having a loadbanged #1karma_pitch_transpose into a prepend send or something. I’ve not used any --- prefixes for send before, and didn’t know that it localized sends. I always thought it was a stylistic thing when I saw it in people’s patches. #1-ing has worked so far for the Max version as I give the top-level karma cores arguments that get pushed all the way down. As devices it’s better to get it locally from the device.

Either way, I’m happy to propagate any changes to tpv2 that streamline things in general. (And I should probably start git-ing tpv2 too. Just been lazy to set it up, and have gotten quite far into the development…)

AND since I’m here, I’ve started working on a cool thing that will function as a ‘wrapper’ for every fx module. Basically each fx will have local presets, modifiers (lfos), possibly mapping, and most importantly something I’m calling “splits” (for now). Or perhaps maybe “divide” or “divisions” as that sounds cooler. It will basically be able to send only a portion of the audio into the fx based on divisions of amplitude (noise gate), frequency (crossover), or noise/sinusoid (median filter). This will work really fucking cool on time-based effects (only the sinusoid part of the sound having reverb added, or only things above a certain volume will go into a delay, or only applying distortion to the frequencies above 400Hz, etc…)

[kza]

@Rodrigo man! everytime you post in this thread my heart beats a little faster 'cause I expect you might announce TPV2

[Rodrigo]

Hehe. I’m making a big push over the summer while I’m not working, so hopefully there will be a beta-able or maybe even 1.0-able in not super long. It’s mainly architecture level stuff I’m working one, and the hardest bit was the parsing/mapping stuff I figured out for BP. That took a while…

[rknLA]

Maybe I should spin out the BP questions into a separate thread then?

Multi-band and gating sounds freakin’ amazing.

o you mean the stuff like sprintf send %ldkarma_pitch_transpose? That could just broken up too, having a loadbanged #1karma_pitch_transpose into a prepend send or something.

Yep, those are the ones, and that’s basically what I’m doing in M4L… [live.thisdevice] into a thing that gets the track number, then sends that into the [monomecontrol] subpatch. I’m not 100% sure, but I think the [send ---whatever] style only applies a device-specific prefix when the object is inside of a M4L device, so it may be completely irrelevant inside of Max alone (though it would be pretty sensible if it behaved like #0 when inside of Max alone)

for git

I ran into some pretty huge bottlenecks once I got things working inside of Ableton, but I’m not sure if it’s something that should be blamed on my computer, or if it’s something that could be fixed by optimization. The main symptom was that, when stopping recording of a loop (say, the third or fourth loop), Ableton choked up enough that it automatically disabled record-arm on some of my tracks, which makes using it pretty unreasonable. The whole point from my perspective was to be able to record the inputs as well as each individual loop separately, and to control sends, pan, and volume for each loop, and Ableton’s auto-disabling runs pretty contrary to that.

Just today I heard a similar sort of hiccup when stopping recording in Max, which was unfortunate, but not fatal, since Ableton wasn’t there to break things by trying to help.

I suspect the issue is a combination of a) my computer (11" MacBook Air… not exactly the fastest horse in the race), and b) whatever [descriptiors~] is doing when recording finishes. If the patch is open source, maybe it’s possible to adapt it so that it doesn’t do all of its processing in a single audio callback? (Though that sounds like a bit of a nightmare of a state machine to try to implement)

I’ll have a look at the real-time version now as well…

The other thing that I haven’t figured out yet is how to handle the combine sections and the input mute, since those will all have to be sent from the loop channels to the input handler (which is new). I’m also not personally using the combine feature really ever, so my motivation to do that is unfortunately low.

Unrelated to all of these things, I’m also now thinking about using multiple channels in karma~ combined with some overdubbing / resampling to get a sort of “disintegration loops” effect as a loop continues, but in a way that preserves the original audio as well. Combined with divided effects, this could be particularly interesting

[Rodrigo]

Maybe I should spin out the BP questions into a separate thread then?

Not much else is happening in here, so I don’t mind! Plus BP is kind of on hold as it all gets converted into TPV2 proper now.

but I think the [send —whatever] style only applies a device-specific prefix when the object is inside of a M4L device, so it may be completely irrelevant inside of Max alone (though it would be pretty sensible if it behaved like #0 when inside of Max alone)

Hmm, does #0 act the same inside M4L? I would imagine(hope) that it does. If that’s the case, I can just split apart the %ld-ed sprintf stuff, to make it easier to adapt. Anything to avoid having to manually change prefixes depending on the version that is being used. (I’m hoping to make the dumping/updating of M4L versions just be a matter of dumping the appropriate version, without having to manually do stuff)

for git

Yeah, once I get the playback modes sorted I’ll git it. At the moment BP is no more as it’s mostly all adapted over to the new UI stuff, and is kind of a mess in general.

Actually, if you want to have a poke at stuff, here is the ‘current’ TPV2, with all UI stuff updated, Combine updated to work with the latest MuBu (may not work with the version of mubu you have currently installed, if not, the latest version is here. the main difference is that it now analyzes the actual buffer contents, including any varispeed/overdub stuff. the older version just recorded the live input into a separate buffer and used that)
http://www.rodrigoconstanzo.com/party/tpv2_test.zip

I suspect the issue is a combination of a) my computer (11" MacBook Air… not exactly the fastest horse in the race), and b) whatever [descriptiors~] is doing when recording finishes. If the patch is open source, maybe it’s possible to adapt it so that it doesn’t do all of its processing in a single audio callback? (Though that sounds like a bit of a nightmare of a state machine to try to implement)

If I had to guess it’s actually the rm.slice subpatch that’s chocking things up. That does a manual/heavy onset detection on the recorded section of the buffer, which can take a bit if it’s a big size. Try deleting the cable coming out of the bang object that connects to prepend rm.slice in karma_slice.maxpat. (looks quite different now):

You’re right in that it would probably be a good idea to try to streamline processing as the moment you hit stop a lot of heavy shit happens (combine, descriptors, rm.slice). Maybe even staggering them would be beneficial. I’ll test some stuff. Basically descriptors crunches stuff to create the real-time presets of slicer/grain/combine (this needs to happen right away, so it doesn’t act funny). The rm.slice thing only effects the onset parameter of the Slicer, so this can actually wait a bit before running. And Combine does some crunching right away too, which effects the concat synthesis analysis (should happen early, but doesn’t need to happen immediately).

The other thing that I haven’t figured out yet is how to handle the combine sections and the input mute, since those will all have to be sent from the loop channels to the input handler (which is new). I’m also not personally using the combine feature really ever, so my motivation to do that is unfortunately low.

This is a simple fix in that it can just bypass the mute altogether. That was just a design decision in that if I was using combine, I specifically wanted no dry audio to come through at all (and any Combine module being ‘on’, mutes ALL audio). But that’s not really needed. So you can just skip the mute code altogether.

Unrelated to all of these things, I’m also now thinking about using multiple channels in karma~ combined with some overdubbing / resampling to get a sort of “disintegration loops” effect as a loop continues, but in a way that preserves the original audio as well. Combined with divided effects, this could be particularly interesting

Interesting! I’m sure you’ve played with the overdub parameter in karma, but it’s meant specifically for this kind of ‘replace’-type overdubbing.

[tehn]

block party, is fun. wow. i’ve been exploring it as a replacement for mlrv in a few of my compositions that need live input mangling.

a few things i’d like to be able to do! (please let me know if these are already there and i can’t see them, or they’re slated for tpv2):

• punch in record replace rather than overdub.
• overdub mix percentage

these are essentially the same feature, but let me elaborate, as this requires a sort of magic playhead:

playback happens, and record adds new material just behind the playhead. with normal overdub mode, 100% of the existing material is preserved. with replace mode, 0% of the existing material is preserved. but then-- 50% mode? slowly perishing buffers. every time the playhead touches data it slightly goes away (or lots goes away).

thank you for your consideration!

[Rodrigo]

Awesome! Glad you dig it.

Yes that’s a planned feature, though in thinking about it now, I haven’t built the parameter into the UI at all, so it may just be incorporated into one of the playback modes. I’ll have a see if I can stick it into the UI as that would make it more tweakable.

The good news is that you can make that happen now by sending a karma overdub 0. or karma overdub 0.5 to whichever karma_core you want to function this way. Can even loadmess it in, or quick-n-dirty MIDI map it in.

*edit : To clarify, this is actually a feature of karma~ itself, so it requires no additional Max coding other than sending the message, and because of how things are structured, you can send any message to any parameter from outside of a karma_core.

[tehn]

long live karma~

such an incredible amount of smart functionality. years ago i patched so many ugly hacks to achieve these sorts of things!

[Rodrigo]

Hehe, and with @RABID’s thoroughness you can even do negative overdub values, which just inverts the phase, so karma overdub -0.5 will blend the incoming audio with a half volume out-of-phase version of what was already in the buffer!

[wednesdayayay]

clever indeed I am excited to get a new computer in the next year or so to play with these ideas again

thank you

[Rodrigo]

Well a lot of it has that super thoroughness (all the ease-in/out flavors etc…)

Good karma indeed, hehe.

[rdfm]

I really tired reading the whole thing again, but alas, is there any solution to the vexpr error? It shows on start up for me