#424

This could be totally unhelpful, but how about representing the data as ‘fields’ of scrolling blobs (maybe on the humble LCD object), that move from right to left, like multislider.

A bit like this Harpex visualisation (that I never get bored with):

But instead space (X,Y in their case) you could have time (right to left).

You could even have them all start in the middle and move outwards in different directions…

This springs to mind too as a bit like what I’m getting at:

#425

absolutely fantastic
and now I see why it’s difficult to settle on a dynamic representative form

5 knobs and a polygon seem ok in my opinion (though I’m not sure how color should be handled for the parameters)

#426

This article provides good rationalization for why radar graphs can be hard to read:

#427

Another take on smooth/chunky.

2 Likes
#428

this is great

can the chunky “lines” be fatter to indicate longer duration?
is there motion involved or are these static?

#429

I imagined them as static, and yes line width variance may be a good idea, although I think @Rodrigo said chunky is shorter?

#430

had to scan above

[quote=“Rodrigo, post:413, topic:247”]
Smooth is faster and periodic grains.
Chunky is slower and aperiodic grains.
[/quote]hard to say what would be best way to show it

#431

Oh you had it right then. Maybe I need that second coffee :wink:

2 Likes
#432

Thanks for all the ideas/suggestions guys!

I should have been clearer with that image, but those are histograms, so just how often each value is present. No time axis at all.

That’s what it’s called!..

…aaand that’s what I shouldn’t use it.

I guess I was going for something like this (p20 of Sam Pluta’s PhD thesis), so each sound would have an identifiable shape, but it would be happening so quickly that it would look like a screensaver.

Hmm, it would look nice, but it (potentially) ventures back towards cool over informative.

Both can be bigger or smaller (size), or closer or spaced (rate), but by and large, the ‘chunky’ are bigger, though the size of each grain is also random in chunky mode (so chunky is aperiodic randomly sized grains and smooth is periodic consistently sized grains).

2 Likes
#433

a graphic representation from what i understand :

2 axis.
(0,0) is perfect match.
(0,+x) is loud
(0, -x) is pitch
(0,+y) is cent
(0, -y) is noise

each segment highlight the gap between perfect match and incoming audio, according to select, loud, pitch, cent and noise settings.

said differently : i have my settings and incoming audio. i see how far i am from a perfect match.

3 Likes
#434

Hmm, as in producing a radar chart/shape for each individual grain? Or showing 4 points/dots?

I really like this idea though, focusing just the difference and incoming audio.

#435

“Incoming audio” is many points, right? While the corpus descriptor boundaries are more like a radar chart, the points would appear in a halo around the descriptor boundary, higher values for each descriptor create a narrower (but sparser) halo close to the boundary, while lower values create a wider (more diffuse, but also more numerous) point cloud, vaguely centered on the boundary.

Even though I said “radar charts are hard to read”, I think these kinds of visualizations in music apps tend to be more intuitively understood. It’s not about the specific meaning of a specific dot at a specific point in time so much as the overall feeling/effect (in an almost synaesthetic manner).

I’m warming up to the radar chart idea, (even if it’s a bit milkdrop-visualizer-ish), assuming we’re not losing something important by dropping the time series. If the time series is musically relevant (are the parameters that define the descriptor boundary changing over time? Can they be sequenced or externally controlled in some way?) then that suggests the types of line graphs (with error bars, so to speak) that you were describing earlier.

Happy to mockup both approaches when I have a moment. (Probably not today.)

EDIT: forgot to mention that another approach to a time series would be to fade out the dots over some period of time after they appear, similar to the way the colored bars showing the grains coming and going fade out.

2 Likes
#436

for each grain of incoming audio, you’d have 4 points (2 per axis).
each point determines a segment, or vector, if you will, from 0.
you’d highlight each segment, with your color chart.
the length of each segment would move at the speed of the incoming audio (the grains).
(although you could smooth the graphic, i guess. it’s just a representation anyway).

2 Likes
#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