#437

Since I can opinionate here: For what it’s worth, I think I prefer the look of these wavy lines visuals (rather than the lines, whether they’re fat or thin or inconsistent).

I think these look cooler and I get the difference right away.

2 Likes
#438

Even though the sine/triangle iconography doesn’t communicate exactly what’s going on, it is more visually striking and distinctive than the ‘long thin dots’.

Yeah. In smooth it defaults to analyzing a 40ms chunk, every 10ms (overlapping obviously).

I guess with time you get a clearer impression of the overall shape/trajectory of the descriptors, though that’s only really to aid the control of select. The time axis can just unfold over time, and be perceptual, instead of literal (graphic).

Man, thank you so much. It’s always a treat to see your mockups. The overall look of TPV2(/C-C-Combine) (and my general design-manship) is all the better for your contributions!

2 Likes
#439

nothing whatsoever to contribute beyond excitement

6 Likes
#440

A large number of bar charts:
https://www.youtube.com/watch?v=KN9ncOHfEDU

Any idea what’s going on in the upper-right corner?

Hey, I haven’t forgotten about you. Been a doozy of a week.

1 Like
#441

Man, I don’t even know, though I am certain that there’s a gigantic baby at the end of it…

Hehe, no worries. I’ve been learning about dictionaries and data structures, so lots of code refactoring and conceptualizing. Really confusing at first, but now I have something much more useful and legible in terms of the “analysis file” that a corpus lives in:

{
“meta” : {
“name” : “Rodrigo Constanzo”,
“title” : “Accordion Noise”,
“description” : “Random noises recorded from a robotic accordion.”,
“date_created” : “2016”,
“date_analyzed” : “2017-04-15 / 02:41:53”,
“comment” : “this is a comment”,
“url” : “http://www.rodrigoconstanzo.com”
}
,
“file” : {
“name” : “accordion_noise.wav”,
“duration” : 326314.0
}
,
“settings” : {
“analysis_version” : “v3.0”,
“windowsize” : 40,
“overlap” : 10,
“units” : 32628,
“fftparams” : [ 2048, 128 ],
“descriptors” : {
“loudness” : “loudness 1 max”,
“pitch” : “pitch 0.6600 median”,
“centroid” : “log_centroid 10 20000 mean”,
“spectral_flux” : “sfm 10 20000 mean”
}

}
,
“minmeanmax” : {
“loudness” : [ -106.759056, -30.991779, -3.235133 ],
“pitch” : [ 0.0, 67.068283, 140.0 ],
“centroid” : [ 46.399357, 91.766556, 125.449028 ],
“sfm” : [ -118.388718, -27.2827, -4.648997 ]
}
,
“analysis” : {
“0” : [ -30.743082, 0.0, 110.99221, -14.119069 ],
“10” : [ -29.847477, 0.0, 102.78936, -18.857525 ],
“20” : [ -30.850266, 0.0, 106.913391, -14.339486 ],
“30” : [ -34.505981, 0.0, 100.441933, -19.840559 ],
“40” : [ -37.735123, 0.0, 96.140182, -22.903746 ],
“50” : [ -45.966511, 0.0, 90.787933, -27.842623 ],
“60” : [ -38.871426, 124.842621, 103.400925, -15.41413 ],
“70” : [ -35.512058, 0.0, 105.463936, -14.856118 ],
“80” : [ -31.557777, 0.0, 114.881561, -7.335074 ],
“90” : [ -24.237932, 0.0, 106.483566, -12.101012 ]
}
}

4 Likes
#442

Ok!

Here is an alpha version of the C-C-Combine M4L device.

Here’s the download link:
http://rodrigoconstanzo.com/party/combinev0.8_beta1.zip

And here are the initial corpora to use with it:
http://rodrigoconstanzo.com/party/corpora_v3.zip

(If you are unfamiliar with C-C-Combine or what concatenative synthesis is in general you can have a look at the explanation of the original Max version of it here.)

///////////////////////////////////////////////////////////////////////////////////////////////////////////////////

There are still some UI/UX things to muck about with, and some other existing issues which I’ll mention below, but I just wanted to get a version of this out there for people to start playing around with.

So some initial bits:
*It’s 32bit only at the moment (though it should play fine on Mac/Win). You shouldn’t need to do anything except open the device.
*Some of the bigger corpora take a long time to load (pinwheel and all). This is normal, and just due to the file sizes involved.
*Automation and mapping should all work fine.
*As far as I know, you will likely need to clear/reload/relearn all of the loaded corpora each time you open Live. This is one of the more complicated parts of the device (and the most new to me, never having made an M4L device before), but this is a known issue/limit at the moment.
*I will likely change the CORPUS section so that it auto-detects the included corpora and populates a menu from that, but for now you have to select the corpora manually.
*Still tidying up the patch that lets you make your own corpora.
*Everything has descriptive annotations, so you can hover over things to find out what things do (quick start guide below).
*There will be a bunch of ‘special corpora’ that will come with the initial release, like a curated “release” of sorts where people will create/donate custom sound sets for people to play around with. There’s one included in the download above from Sam Andreae.

Things to check out:

  • General usability. Does it make sense? Is it confusing? etc…
  • General mapping/naming. Do things work, automate, and map/behave as expected?
  • Does anything crash or otherwise act funny?

In general I welcome any/all comments/suggestions, from UI/interface/color, to bugs/crashes, to general workflow improvements etc…

///////////////////////////////////////////////////////////////////////////////////////////////////////////////////

Now when it’s released released I’m going to put it out with a nice blog post explaining shit in detail, some performance videos, a couple tutorial videos, etc… all trying to help with the concept and how to go about using the patch. But here is a simple ‘getting started’ guide.

  1. First up is loading a corpus, by pressing the flashing “load corpus” menu in the top of the CORPUS section. Point it to any of the .json files (the corresponding audio file is loaded automatically).
  2. Once a corpus is loaded, the device is ‘running’. If you play audio through it, you’ll hear it resynthesized by the loaded corpus, by default.
  3. You can load additional corpora to easily be able to switch between them using the same menu. (You can also select the current, or all loaded corpora, so you can get really interesting results by choosing what corpora you choose to load).
  4. Most of the change in sounding results will come from the PLAY section. Play around with the smooth / chunky toggle, and smear. Pitch and glitch have more extreme impacts on the sounds, as do the various envelopes you can apply to the grains.

More advanced bits:

  1. Once you are playing audio through it (at least 5 seconds worth), press the LEARN button in the CORPUS section. This will match the input audio to the corpus so that you can access more of the corpus based on your input (like if you only have high pitched sounds, you can still trigger low pitched sounds in the corpus). You can then press the NORM button to enable the normalization.
  2. The MATCH section tunes the matching engine. You can tweak the select knob to get more or less matching overall.
  3. The individual descriptor knobs in the MATCH section lets you dial in really specific querries since the underlying code will reorder based on how the knobs are set. For example, turning a descriptor knob all the way down stops searching for it, so play with these knobs to get some quirky settings (centroid and pitch turned all the way down, with loudness/noise turned up 3/4 of the way).

So yeah, have a play and let me know how you get on.

///////////////////////////////////////////////////////////////////////////////////////////////////////////////////

The main things that will be changed is the recalling/reloading of stuff, so that reloading a Live set should recall all the loaded corpora, and learn/normalization settings. This is a pain in the butt since it’s large data sets, but should be doable.

I do plan on changing the UI a bit more as well, but I’m open to general suggestions/improvements, so let me know what you think.

15 Likes
C-C-Combine (M4L) beta
#443

This is brilliant! :heart_eyes:

There is a lot of fun in it just with a reverb afterwards when you are patient enough with the corpus loading to realize that it actually is not broken but really takes looooooong…

Sounds great and the stereo feature is beautiful! Still have to figure out how the match knobs interact with the signal.

One thing I found is when I turn down the noise knob to zero even with the output blend fully dry there is some digital cracking on the signal as if the processing is not fast enough.

2 Likes
#444

Glad you dig it!

Yeah, some corpora take forever (the sax and plexure ones are particularly huge).

Hmm, what might be happening is that it’s always matching, so if there is hiss coming or something, it will match from the quietest sounds in the corpus. (Are you sending it digital silence, or something plugged in but not playing?)

The noise knob (and the rest of the matching knobs actually) only effect the weight of that descriptor when matching, so how fussy it is about each component. So turning the noise knob down will just mean it will ignore noise when matching grains. That’s not to say you won’t get noise at all, but rather than it won’t be looked at.

1 Like
#445

Maybe I did not explain it right - it is not that there is some sound/noise even when I don’t feed any audio in. It is that the audio I feed in is distorted even with the output blend tuned fully CCW. And the distortion fits with the grain selection as it is shown in the small play display but is not connected to the sound of the loaded corpse.

BTW it is pretty hard to turn the knobs to zero sometimes - they tend to stuck somewhere on the last 5 %.

I am on Ableton 9.7.2. btw and Mac El Cap.

#446

Ah right. Hmm, I’ll test that out.

The knob thing I’ve encountered too. It’s not ideal, but it’s how I’m “faking” the look of those knobs. There are regular (but invisible) Ableton-style knobs on top, and those are what you are turning/controlling, but if you grab them towards the edge (for whatever reason), that happens. The same happens with the actual Ableton knobs, but not if you grab the center.

#447

The Aalto-inspired design of those knobs kind of encourages grabbing from the edge. :-/

3 Likes
#448

I’m not getting any of those. Could you make a little recording of this? Or even better, a little phone video of the screen showing what’s happening?

For the next iteration I’ll line up the ‘invisible’ knobs a bit better. I erred on the side of the square bracket thing lining up right, rather than the actual ‘knob’ UI element, but that makes it a bit harder to grab.

I actually thought about going with a regular Live knob for the M4L version of Combine, but I didn’t want to have to develop two separate UIs for the Party-based stuff I make. So wanted to keep it consistent with TPV2 look/feel.

3 Likes
#449

While doing a phone video of the cracking behaviour I felt that it is har to replicate. It seems that is a mix between knob positions, actually moving knobs and the movements on the play screen. Don’t know if you can make it out in the video but there are graphic glitches too where the whole GUI disappears in a very short flash (around 00:34).

Before I did the recording it was a bit different in that the centroid knob has a bigger impact on the craking than the noise knob. It is a bit inconsisting but looks like this:

Damn, I did not expect the sun to come out - sorry for the inappropriate clothing…:flushed:

1 Like
#450

Thanks, that helps a lot actually. So those little crunching sounds are what you are referring to yeah?

What does the CPU usage read in Live (or in activity monitor)? It sounds a bit like the cpu not being able to keep up. Also try this, turn one of the single matching knobs all the way up (so the blue lines in the display stop) and see if the crunching still continues.

Basically when you turn the knobs all the way down, in order to still match something (as in, you are telling it to “find whatever”), it looks for stuff based only on loudness, with a really high tolerance. What this means is that it’s scanning through a HUGE database, a lot, for every grain, so it’s quite intensive. In an earlier version of this I was getting crashing as a result, so I refactored stuff so avoid searching for “whatever”.

If that fixes the problem, I’ll just reduce the aperture on the loudness query when everything is turned down.

And the flashing is a weird thing I’m seeing too on mine. On mine it happens even more than in yours. I’m not sure why it’s doing this, and it seems to be M4L-specific behavior (as in, it doesn’t happen in Max at all), so I need to test more to find out what’s up.

1 Like
#451

When I turn the knobs down with a higher rate both the action of turning the knobs and their state being turned down increase Live’s CPU display up to 200 - 300 % and the internal CPU usage of the MacBook (Pro, 2013) up to 90%. bringing up the match knobs and reducing the rate a bit brings Live’s own CPU usage display down to 70 % and the main one down to 35%. This is all in Smooth mode.

When I am in Chunky mode I still get cracks with Live’s CPU display jumping between 3 and 30 % and system CPU usage for Live at about 30 - 40 %.

Normally Live’s CPU display is under 10 % with all knobs set to somewhere medium and I have no cracks then.

All this seems to be dependent on the select knob position, which corpus I use and if I use more than one.

Though I did not find a way to let the blue lines disappear by setting on of the matches to max.

What might have an influence too is that often when the knobs look like turned fully ccw they actually are not. Low settings here seem to be more problematic than off settings. I understand that setting limiting the choice by setting match parameters makes it more stable.

BTW: What does centroid mean?

#452

Ok, that’s pretty heavy. I’ll limit the upper bounds of the rate, and the lower bounds of the “all off” descriptor matching, so it can’t get that high.

If you really want to fry it, the absolute worst would be having the rate AND size maxed, as that will play really fast, and have tons of overlapping grains…

That makes sense too. The bigger the corpus, or when you have multiple corpora loaded (and are in ALL mode), the more CPU it takes to look through, as you are querying the entire database per grain.

If you crank the ‘select’ knob up too, that should help. That controls the overall multiplier for each of the individual descriptors. Think of it as a master “more” or “less” knob, in terms of matching. Even just cranking that knob with default descriptor matching settings should reduce the amount of blips to near zero.

That’s exactly it, and that’s what was causing crashes initially. With low knob settings, it’s almost literally checking over the entire database per grain of playback, so I needed a way to override that. At the moment, whichever descriptor is set the highest gets checked first, to rule out as many matches as possible, then it wittles down from there, but having low (but non-zero) settings, is the most CPU usage. And turning it off completely just stops checking that descriptor completely, which uses less CPU. Let me know if you find those lower edges useful, as I may dial the limits on that back as well, to reduce the overall footprint.

The centroid is where the bulk of the energy sits in the spectrum, but it essentially is perceived as “brightness”. What I label as “noise” is actually a measurement of spectral flux, which is perceived as noisiness.

#453

Is there any way to run this if I have the 64 bit versions of Live and Max for Live installed?

1 Like
#454

At the moment, unfortunately no.

The core externals are 32bit (though this will be remedied for the final/proper release). I just have go beg/plead Alex Harker to bounce the 64bit versions of all the plugins for me.

1 Like
#455

OK, I guess I’ll try installing 32-bit versions of live and m4l then. Because, I’m curious! I wonder if they can be installed simultaneously? (64 and 32 bit)

1 Like
#456

Yes, I have both and use both with different plug uns and Max versions - it’s just hetting a bit difficult to remember which enviroment for which task…:smirk:

4 Likes