App - The Party Van

[Rodrigo]

It’s definitely a Madrona-ism there.

I’ll have a play with it once I start actually moving things over to the new UI, but even as it’s stands its significantly more legible than TPV1 (and my sketches for TPV2).

In the middle of a big push on the glitch mode as of late (lofi/tape modes done already). Probably going a bit overboard with the authenticity, but I’ve made close to 150 tiny samples of all sorts of different clicks, and blips, as well as analyzing the pseudo-random variations in timing between glitches (it’s not purely random, but rather clumps to certain tempo variation/modifiers).

Once I finish up a few modes, I might try to revamp BP with some of the UI stuff, and try to include the playback modes as they sound cool as shit.

Here are the planned presets for the glitch mode:

glitch:
discmn - just glitching sounds
chclate - random position/window + glitches
^^trig - jumps around based on playback onset detection (position determines window size?)
^^poke - audio input onset-detection jumping with dc noise overload
^^rand - randomly jumps around on timer (based on window size)
>>trig - seeks around based on playback onset detection (lockout/seek sound)
>>poke - seeks based on audio input (with loud bits triggering zipper seek)
>>rand - seeks around on random timer (based on window size)

And yes, have fun in Cuba!!

[lintfresh]

Hmm, looks like the file is too big to upload directly to this post (3.2MB???) so here’s a dropbox link:

Dropbox - Error

I altered the Karma subpatch so hopefully I included it correctly. In all my years of dabbling with Max I’ve never really had to share anything so forgive me if it doesn’t work.

This is obviously a hack and just a temporary solution until you’ve released your new new version with amxd’s, but I’m working on a new multimedia dance work and need to start using this stuff in our rehearsal process to see if it’s a good fit.

Thanks for any help!!

[angel]

I really liked the palette from the Jardim Zoológico de Cristal poster, so I thought I’d give it a try and make a couple custom skins Thanks for the inspiration @jasonw22

[Rodrigo]

This is obviously a hack and just a temporary solution until you’ve released your new new version with amxd’s, but I’m working on a new multimedia dance work and need to start using this stuff in our rehearsal process to see if it’s a good fit.

Not tried it with a monome yet, but a quick look over and I think some of the issues might be that it needs an argument given. For many things the “#1” argument will be fine being set to zero, but there are probably a couple of places where it’s expecting something other than a zero in order to work right.

Try giving karma_baby_core.maxpat an argument of “1” to see if that fixes the problem(s).

I really liked the palette from the Jardim Zoológico de Cristal poster

That looks amazing! You guys are gonna make me have to include customs skins in the end…
Also in seeing this original layout, I really like what you (@jasonw22) did with the spacing and weight of stuff. I wasn’t (initially) sold on the smaller ‘speed’ knob, but it definitely looks cleaner in your version.

[lintfresh]

Ok, set a 1 as an argument and it seems to help, but still having problems.
It’s mostly not detecting my monome, but on the occasion that it does detect, it seems to be working ok until I engage the slicer, then I immediately get vexpr stack overflow again and it freezes.

[Rodrigo]

(Un)relatedly, I’ve had trouble with the newschool serialosc not connecting if I’ve closed/reopened a patch in Max, but that could be down to my OS or some other funny business. And generally the vexpr breaks the page handling, so things get “stuck” in an inbetween state.

So you’re getting a stack overflow immediately when you turn on Slicer? (unrelated to the alt menu stuff?)

[jasper_ryder]

@Rodrigo,
I get the same thing with m4l patches and serialosc these days. I just get a ‘none’ in the dropdown menu. Kind of annoying. OS X 10.11.4

[tehn]

we need to get more debugging into the dropdown menu business. apple is making headaches.

[lintfresh]

Ugh. I don’t know honestly. It’s behaving differently every time I open it. It makes no sense.

Right now what’s happening is I drop the device into a project. It shows up with a vexpr stack overflow warning. I clear that. It usually recognizes the grid. All the controls seem right except when I try to record something into the buffer it won’t let me. Stop, record, pitch up/down don’t work on either the GUI or the grid. Alt menu seems to be there ok on the grid. I can engage grain and slicer stuff but without audio in I can’t be sure it’s working at all. Then this is about the point where I get another vexpr stack overflow warning and everything on the grid starts to go all weird.

Anyway, I realize that it’s practically impossible for you to help me troubleshoot with such inconsistent behavior, and honestly the time I can spend on this is quickly running out as I really need to be actually writing music and rehearsing it, so I’ll just bow out at this point. Thank you so much for all your generous help and sharing of hard work/knowledge.

I really look forward to the new version of this brilliant thing you’ve created.

[Rodrigo]

Yikes, yeah that sounds like a pain. I really suspect there’s something unusual with vexpr, as I had some inconsistent issues while developing too. Just not enough to nail down a problem to bug report it.

I recommend removing the altMenu subpatch and/or just mapping the controls from the alt menu onto a different row or something for now, so you have something functional.

[lintfresh]

Great advice, I’ll give it a shot. Thank you.

Glad to hear I’m not the only one having issues with vexpr. Thought I was going insane.

[rknLA]

Holy wow, there’s way more to this thread than I realized. I was trying to catch up, but I’m still only at posts from March. I’ll catch up soon…

I had a really nice jam on Block Party 0.5 last night, and wanted to provide a few thoughts, either for subsequent BP revisions, or to incorporate into TPV 2.0. Before I jump into the list, I should also say, this work is really freakin’ amazing, and I’m really excited to explore it more. And also thank you for building and sharing

Apologies if these are things that have already been mentioned, fixed, or resolved.

1. +1000 for scrolling in the UI if it’s going to be that big. For those of us with shrimp for laptops (i.e. 11" Macbook Air), keeping scrolling enabled is a great help. I can’t change the A440 in the tuner in TPV 1.0 because my screen isn’t tall enough, so I still have to use an external tuner.

2. The “aux menu” thing per row is really, really intriguing from a workflow perspective, and seems to make a lot of sense to me. One thing that’s difficult about it, though (aside from being on a grayscale non-varibright monome), is that I wind up tripping over myself trying to record a pattern as I’m playing. If I’m jamming on a row, and find a groove, it’s pretty distracting to try to figure out where in the rhythm makes sense to select the alt button, and to start recording. Since it’s nested in the same row that I’m actually playing, I have to stop grooving on the buttons, then push through to trigger pattern recording, then try to re-enter the groove.

3. I keep confusing the half and double finger gestures. It might be helpful to have those gestures trigger some kind of animation to indicate speeding up or slowing down (maybe as simple as a light blinking on the right for speedup and left for speeddown, or maybe sliding a light under the fingers, again with leftward meaning slowdown and rightward meaning speedup)

4. I ran into this a few times: It seems like after stopping a row (using the 3-button gesture), I couldn’t trigger playback again until I’d begun a new recording. Not sure if this is a bug, or by design, but it was pretty frustrating.

5. I tried and failed a few times to get midi mapping to work so that I could use a KMI 12-step to trigger loop recording. Is this implemented, or just still present in Settings because it’ll be in TPV?

I think that’s it… Thanks so much again for making such wonderful works of software.

And looking at the last few posts, I also ran into this none device issue, and had to iterate through a few variations of (kill the serialoscd process / unplug / plug in) in order to get my device to show up again. I might’ve even had to restart the whole machine. That’s probably not an issue with the app though.

[Rodrigo]

Hah, yeah this thread is definitely verbose…

+1000 for scrolling in the UI if it’s going to be that big.

The later betas had scrolling enabled (unless I accidentally disabled it again at some point). TPV2 should be smaller (along the lines of the UI mockups), so it should hopefully fit on more screens. I’ll try to be more precise to where objects pour off the UI screen as the only reason I disable scrolling is that it annoyingly scrolls when you hover near an edge.

I wind up tripping over myself trying to record a pattern as I’m playing.

I agree, those 4 buttons in there (slice/grain/combine/pattern) are only a stop-gap. I’m going to come up with with some fingering patterns for them as well, though probably 2 hand patterns (ie holding down the leftmost button + a pattern somewhere else). I want to be able to engage/disengage those things on the fly.

I keep confusing the half and double finger gestures. It might be helpful to have those gestures trigger some kind of animation to indicate speeding up or slowing down

There’s totally animation gestures for these (you can see it in the quick demo video). When going up an octave there’s a flash/pattern on the right, when going down there’s one on the left, and when you come back to 1x, both sides flash. In generally I think the ‘fingering’ will take some internalizing, but after that, it should feel like second nature.

I ran into this a few times: It seems like after stopping a row (using the 3-button gesture), I couldn’t trigger playback again until I’d begun a new recording.

This is actually a bug with karma~, which I’m hoping to iron out (with some other small improvements/features) with @RABID in a karma~ 1.1. Basically if you send stop/play/record messages to karma~ immediately after each other, it can sometimes break the state machine. I’ve hacked a little workaround that waits something like 15-20ms after each message, but very rarely this still gets locked out.

I tried and failed a few times to get midi mapping to work so that I could use a KMI 12-step to trigger loop recording

@dan_derks Was having a mapping issue too, though that was due to scripting name issue with all of the cores getting redundantly mapped to the first one. It should be working, though I haven’t properly tested it (I did get a korg nanokontrol for this kind of stuff). Did you get it working in the end with the most recent beta @dan_derks?

Are you using the KMI in a regular MIDI mode or is it sending sysex stuff into Max? (I remember for my Softstep (using Jeff Kaiser’s objects) that it piped in raw sysex that was then ‘cooked’ into MIDI).

I might try to incorporate a better MIDI learn system in TPV2, or include more clear instructions. I personally never use it, so I always looked at it as a kind of bonus feature for people, rather than being meaningfully integrated.

[rknLA]

Indeed, in catching up and rewatching the video, I see that none of these are really still issues after all…

The later betas had scrolling enabled (unless I accidentally disabled it again at some point).

Yep, I meant this as in “yay! scrolling! it’s here!” rather than “it would be nice to have”… basically +1000 for keeping it, really.

I still haven’t gotten the animations for the increase / decrease speed to show on my device, but this could be an issue with the libmonome / varibright code that I wrote. Or possibly that the brightness of the animation is too low for it to show on this old thing

Is the play/stop rate thing in karma~ is because play gets sent on the first button press, and stop gets sent when the whole gesture is recognized? Cause I wasn’t trying to stop in the context of other button presses.

Are you using the KMI in a regular MIDI mode or is it sending sysex stuff into Max? (I remember for my Softstep (using Jeff Kaiser’s objects) that it piped in raw sysex that was then ‘cooked’ into MIDI).

I believe it’s in normal MIDI mode, but I’m still pretty new to this thing. I’m able to see input data in the notein example patch, but that also makes me notice: since the 12-Step (and I assume the Soft Step) is pressure sensitive, it’s actually sending real velocity instead of just 127 for on, and 0 for off. Would that make a difference? And are the record, play, and stop buttons mappable?

Some kind of feedback when the parameter is mapped, or the ability to see which mappings currently exist might also be handy.

[Rodrigo]

Or possibly that the brightness of the animation is too low for it to show on this old thing

The animation peaks at 6, and its tapered at the edges, so the ones next to it peak at 4, then outer ones at 2. When I was coming up with animations I didn’t think (at all) about binary compatibility, unfortunately. I guess it meant I was able to come up with some kind of slick/novel visualizations, but at the same time, I’ll have to properly think where a threshold could be drawn.

Is the play/stop rate thing in karma~ is because play gets sent on the first button press, and stop gets sent when the whole gesture is recognized? Cause I wasn’t trying to stop in the context of other button presses.

No it’s more that when going to “jump” directly from record, it has to send “record” (to stop recording), “play” (to begin playing), then “jump 0.3” to jump to wherever you pressed. It happens as a single “thing” to you as the user. As I said, this is a bug that should be ironed out. The manifestation of this is, for the time being, every once in a blue moon, it gets ‘stuck’ in play or stop kind of thing. I can add more to the delay between the messages, but I wouldn’t want to compromise the feel of 98% of the presses, so the 2% don’t fuck up. (wait, does that make me a socialist, or a capitalist?!).

And are the record, play, and stop buttons mappable?

They should be. I know the play/record weren’t mappable in Cut Glove because of how I set things up (the thing you pressed was a UI overlay, instead of a real button), but I changed that for BP/TPV2. It’s still technically an overlay, but the overlay is a real button (live.text) instead of a fake one (ubutton).

Some kind of feedback when the parameter is mapped, or the ability to see which mappings currently exist might also be handy.

Yeah I need to revamp the MIDI learn completely. I just need to figure out how to best display what is available for mapping, what has been mapped, and potentially include scaling/ranges/etc… (like in Live or something).

[rknLA]

The animation peaks at 6

Ah yep, that’ll do it then, cause the compatibility layer in libmonome only turns the light on if it’s above half-way (8-15)

So, if it starts at 8 instead of 6, it’d flicker just enough to see it. I guess actually designing it for the older grids would be better, but that’s a lot more work.

I can add more to the delay between the messages, but I wouldn’t want to compromise the feel of 98% of the presses, so the 2% don’t fuck up.

A buttonevolent dictator maybe?

Special cases are the worst, but maybe it makes sense to route the “play” trigger through a gate that checks if it’s recording, and only add the delay in that case? Bandaids. Fixing the actual message handling in karma~ is probably a better idea, but probably a lot more wor-- Wait a minute, I’m starting to see a theme here…

[rknLA]

Man, I just wanted to say again, thanks so much for Block Party. This is so close to what I have been planning to build (and have taken some baby steps towards, but not fully realized), and playing with it is has been amazing so far.

I’m going to take some time to jump into the Max code this week to see about making a few mixing-related adjustments, and possibly get this into M4L, since I’ve just discovered that I can’t MIDI-control the dang Universal Audio Console app.

I’m also seeing a weird situation where sometimes the mlr-playback-position lights aren’t showing up for some rows. I’m not sure if this is an issue with my device (which does show fun blinking lights on the full grid at app-launch), or if there’s some lower intensity stuff happening, or if there are bugs in my libmonome code.

[kza]

A M4L version of Block Party would be great!

[madeofoak]

agreed, thank you so much, @Rodrigo. loving it to the point that it might be my main hub for the next improv setup i’m putting together for some sets this summer. seriously great work. can’t wait to see tpv2.

and +1 for an m4l version, though that seems just greedy at this point.

[Rodrigo]

Glad you’ve dug it. I’m pushing forward more and have most of the UI stuff actually implemented now. Streamlining some controls and other bits like that, then will go back to trying to wrap up the different playback modes.

I do look forward to making a bunch of M4L things out of the components, as they would be awesome to have in a DAW environment (I’ve slowly been learning Live…finally).

There could very well be a bug in how stuff is displayed. I actually haven’t played with all 8 rows at once very much (other than to test it worked). If it helps narrow things down, all LED messages are set exclusively with /monome/grid/led/level/row 0 <row> <16 value list> messages.