That’s a really nice feature, Rodrigo!
Excited about what you’ll be putting together in 2.0.
Let me know if I can help with the manual again once you’re done.

This is going to get me off my ass and building a 128 kit. Really looking forward to it.

1 Like

will be still available the control of the app whith a shnth?

Oh yeah, I forgot I even put that in there! I didn’t know or think anyone used it.

I’ll probably leave that part in tact, but maybe reworked with the newer routing options.

Hi @Rodrigo et al. I use TPV as the basis for my setup, and i’d like to add a video component. Basically, I’m imagining a scenario where video clips or video fx are triggered in tandem with the button presses of the monome. For example, if I hit the stutter button, it would also cause a video input to stutter. When I use the looper on some audio, it loops a video or futzes with the parameters of some video fx, etc.

I don’t need the video functionality to be as complex as the TPV is for audio, as long as there was some kind of relationship between sound and image.

Is this even technically possible? Could I conceivably split the monome signal and create a new Max patch that processed videos using the same midi signals? How tough would it be to do? Could I get away with triggering the video FX on the same Macbook Pro, or would I need a separate computer? Could I do it on a Raspberry Pi?

I’ve never created my own monome patch, but I’m motivated enough to try now. Crush my dreams! (Or say, “If you will it, Dude, it is no dream.”)

Hi @kidatonal!

You’ll be pleased to know that the connectivity part is relatively trivial. There’s hardcoded sends/receives to most of the objects/controls/effects in the patch, so you would just need to figure out what you want to trigger stuff, and then find the appropriate send/receive.

In terms of ‘best practice’, you should tap into THAT stuff, as opposed to getting messages from the monome, as that can break things if you then mess with the GUI and/or control things via MIDI. The first couple TPV versions worked that way, and it was a nightmare as a result.

In fact, I’m currently doing something very similar, in tying a bunch of DMX/light stuff to controls in TPV (actually Cut Glove, but very similar), so it’s just a matter of ‘abstracting’ as much as possible, and compartmentalising what you want to do.

Once you have the sends/receive sorted, then you should build the video stuff separately, eventually connecting the two parts together.

As far as the video stuff, it really depends on how hard you want to push it. Video is, generally speaking, more CPU heavy than audio stuff, since its multidimensional data, and lots of it…
I do know most ‘pro’ VJ types use two computers, one for audio, and a separate one for video, but that really depends.

A Raspi would be a step in the wrong direction, I think, for video anyways. It’s more a functional computer that can only really handle simpler (audio) tasks, and even then there still isn’t an easy/elegant way to run patches on a Pi.

So my advice:

  1. figure out what you want to use as the ‘control’ from TPV. be specific (e.g. the ‘record’ button from the stutter effect)
  2. build the video equivalent of these FX completely independently of TPV
  3. connect the two things together (and see if it can happily run on one machine)

@Rodrigo you are a wise man, and fast.

How hard is it to figure out which parameters are what in the patch? Is there a map?

Man, can’t wait to make this happen! If it’s good, do I have an obligation/opportunity to share it with the monome community?

Ooooor, can I re-assign parameters from an existing video processing patch such that they respond to TPV hits?

It’s not that hard, they are just spread all over the place. Most of the important sends are in one place, because of certain MIDI mappings, but you want the receives (since you want to do stuff based on things happening IN TPV).

TPV is also a pretty big app, so there’s dozens of files, so the best way to find them is right click on an area that has what you want to control (e.g. stutter), then select “object -> new view of xxxxx.maxpat”. Then that will open up the subpatch. Then do the same thing in that subpatch until you get “down” to where the individual parameters/sends are.

And yeah you can totally connect it to an existing video control thing.

Oh, and no need/obligation to share. None of TPV stuff is open source in “that way”. So use what you want, to do whatever you want.

Is the new partyvan gonna work for us 64 users as well? Or will it be 128 only?

It’s going to be 128, mainly because that appears to be the “standard” now. Plus there’s a lot more tools now for spanning/combining grids, so I feel less pressure/desire to build that directly in to the app.

I’m going to release an ‘in between’ app soonish that will be 8 core sampler/slicer/grain/combine modules, each mapped to a row, as there’s lots of cool stuff in there as it stands, and so people can play with it.

It might be possible to make that work for 64 too, but will see. Because of how I’m using the space, some of it is hard wired to row width.

2 Likes

this new 128 revision sounds like it’ll be something special… which tpv already was…
( preset morphing ? ) concatenateive whatsissis !

only thing I’m curious to know is if there’ll still be a tml / c-g aspect…or the ability to trigger record or adjust the buffer(s) via an arc …
that and support for non variable brightness 128 grids ?

anyway. tpv is great I’ve played out with it a few times and have always been stoked with the sheer depth and variety of sound it can conjure from relatively minimal input. I should really donate or buy some recordings… /

soon.

peace

Yeah, there’s some crazy new shit, along with 200% better versions of most of the stuff that was there before. The new ‘in between’ app will be called Block Party, and should show some of the new stuff.

Initially there won’t be any arc control, as it will literally just be a 128 grid (for Block Party), but once I get an arc4 (hopefully they come out this year), I’ll start building TPV2 proper based on that. It will require completely different thinking, as I used the press+turn thing a lot in TPV1.

It should work with non-vari grids too. I think the more recent serialoscs handle that already, but if they don’t, I’ve got some code that auto crops things so it works.

And no need (or desire) for any donations or buying things. I’m trying to completely separate money from art, which is, thankfully, relatively easy to do!

3 Likes

@Rodrigo, please don’t make me buy an Arc4 :wink:

1 Like

Hehe, we’ll see what I can do.

The arc2 will definitely work with it, you’ll just have 2 less knobs is all. That scales easier.

(a little OT, and somewhat inspired by the 2020 app thread in how cool that app looks, but are any of you graphic designer types and/or is anyone interested in helping me revamp the look of tpv for tpv2?)

1 Like

Yes, I would love to help with UI design tasks. (Happens to be my day job as well.)

I would be sincerely absolutely thrilled to help out. We should chat more about your ideas. TPV is already one of the sexier Max apps around, so I’ll be eager to hear about how you’d like to improve on it.

And I agree that 2020 looks super slick. (I really liked the way the grid sequencer elements resized in the videos)

2 Likes

Man, that would be amazing! Like super super amazing!

In general I think I want to keep the general ‘tightness’ of it, with everything being compact, and number-oriented-ness, but really like how differentiated each section of 2020 looks. Plus, it doesn’t looked as cramped (as tpv), even though there’s tons more (visual) things going on.

It would actually be really interesting to hear your thoughts on UI stuff, especially as you’re an actual designer!

Probably best to move this out of this thread as to not jam it up, but my email address is rodrigo.constanzo@gmail.com .

!!!

2 Likes

Ok!

So here is the first beta of Block Party:
http://www.rodrigoconstanzo.com/party/blockv01_beta5.zip <==updated!

(it’s packaged up as a “Max project”, so you shouldn’t need to deal with any externals or anything like that, it should just run as is)

I’m still working on the pattern recorder, so at the moment it only captures/plays back on-screen controls, but everything else should be working.<== (no longer the case, pattern recorder is implemented)

The basic gist is that it’s 8 rows of newschool ‘karma core’ modules, build around varispeed 128s. Everything is basically new and improved under the hood, but the main layout and control paradigms are different.

Here’s the mapping details from the ‘info’ window in the patch:

Each row represents a karma core module (looper, slicer, grain, combine, pattern, and brain modules).
Everything is controlled by using monome “fingering”, which can be used anywhere on the row.

The fingering patterns are as follows:
1 = play from that position
1 1 or 1 0 0 1 or 1 n 1 = create a loop between two points
1 1 1 = stop
1 1 1 1 = record (or overdub, if in play mode already)

1 0 1 1 = half speed
1 1 0 1 = double speed
1 0 1 1 0 1 = reset speed
1 0 1 0 1 = reverse

Fingering combinations can be combined, for example:
1 0 1 1 0 0 0 1 0 1 0 1 = half speed AND reverse
1 0 1 0 1 0 0 0 1 1 1 = reverse AND stop

These fingering combinations can happen anywhere on a row:
0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 = play from 5th slice
0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 1 = reverse
0 0 1 1 1 0 0 0 0 0 0 0 0 0 0 0 = stop

Pressing and holding the right-most button brings up the alt menu. The alt menu allows you to control the “tilt” of the row, as well as enable the slicer/grain/combine/pattern modules.

The alt menu is broken into two main parts.
The first four buttons are the on/off for the slicer, grain, combine, and pattern modules, respectively.
The middle 7 buttons are the “tilt” controls. When in the central (default) position, all sample slices are equal, with increasingly eased in and out versions moving outward from there. When changing the “tilt” or the row, everything recalculates so any loop that has been defined will be redefined based on the new tilt.

Here’s a real short video showing the general ‘lay of the land’ for a single row:

So the main things to test are just the general playability and control of the “fingering” paradigm. I think I have it tuned pretty nicely, but occasionally some things misfire. It’s a tradeoff between accuracy and latency, as is often the case in programming.

I put a ton of time into the different animations for each mode, so let me know if they are distinct enough and/or communicate enough about the state of the system. Moving completely away from one-to-one button mapping and state LEDs has required a bunch of signifiers and stuff to communicate info (e.g. what happens when you engage half or double speed).

Other than that, just have a play with it and let me know if any issues crop up.

Once the pattern recorder is working fully/correctly, I’ll post a 2nd beta that includes that along with any bugfixes that have cropped up. Plus I want to revamp the GUI, though that might properly wait until TPV2, with Block Party retaining that oldschool TPV1 look. Either way, the big empty stripe at the bottom is kind of funny looking.

Also, here’s a clarification on what the ‘tilt’ does. It applies the following ease in and ease out functions to the karma~ playhead, jumps, and loops. So it gives you higher resolution towards the ends, and overall different sized loop slices in the same row, so it doesn’t sound so ‘evenly spaced’ overall.

18 Likes

If anyone uses windows, I’d like to include the MuBu externals for Max in the same package, but for some reason they are distributed as an .exe. So if a windows user is up for downloading/installing the 32/64bit versions of MuBu from here and sending me over the package folders that these installers presumably generates, I can add them to the ‘package’. This should hopefully solve the mess of having to manage/install a bunch of different externals.