Dead Man's Catch modified firmware for Peaks


#321

@pichenettes that’s true, but I still think there merit in a single octave inplementation. You can always use two of the modules, or mix the output with another LFO.

Also, I’m not sure theres necessarily that much to be gained by modulating the coordinates with an external voltage. I see this more as a way of exploring ‘pattern space’ manually until you find something that works musically, then being able to call up the same pattern in the future.

a|x


#322

toneburst> Incidentally, going back to your idea of having multiple patterns at once; couldn’t you just scan across parallel lines, with different Y-axis offsets? You could have a ‘Spread’ control to create more of less closely-related patterns.

Yes, that’s what I have described, two or three times, above… the lines don’t need to be parallel, either, as I described.

toneburst> Of course, having more than one pattern multiplies the processor load (I don’t think there are any shortcuts here).

I don’t think it is terribly computationally intensive at modulation or pitch CV rates. For audio rates, maybe that’s an issue. There’s only one way to find out…


#323

toneburst> I still think there merit in a single octave implementation… also, I’m not sure theres necessarily that much to be gained by modulating the coordinates with an external voltage. I see this more as a way of exploring ‘pattern space’ manually

Single octave is just the degenerate case of fractal noise - the ability to mix several octaves doesn’t preclude the ability to set the gain on the higher octaves to zero. Likewise, having CV control of the co-ordinates being read from the map doesn’t preclude manual control.


#324

All true, I suppose.

I still don’t honestly see the point in moving across the noise field in anything other than a straight line, though.

If you were to draw a line or curve on the PN texture in my example diagrams, and plot the values of the pixels under the line, do the same for a horizontal line along the X axis, and I’ll bet you can’t spot any qualitative difference between the two graphs, that would justify the additional computational overhead.

Your use of the term ‘degenerate’, implies to the lay reader a somewhat arbitrary value-judgement (though in sure it wasn’t intended that way).

a|x


#325

How about having additional controls to control the amplitude of, say, 2 additional octaves of noise.
The two additional octaves would share the same start coordinates and offset, and their scale along the X axis would be (fixed or adjustable) multiples or divisions of the ‘base’ octave X scale.

a|x


#326

Malaclypse is now on Modulargrid .
It does sound great, I have to say. I do still think it’s a significantly different (though obviously equally valid) take on interpolated noise to what I had in mind.

a|x


#327

I guess I have some quite strong opinions of this because I’ve been thinking about generating patterns in ‘parameter space’ for realtime performance in various forms for some time now.

In the past I’ve been primarily interested in visual patterns, but I’m now really interested in how I might be able to apply some of the same techniques in the audio world.

Here’s an example of something I did using GLSL some years ago:

https://vimeo.com/987514

It’s a GPU-accelerated raycast rendering of an isosurface of a 3D density field. I’m controlling the various parameters of the equation used to generate the density field in realtime, using a combination of manual controls and audio-level modulation.

Of course, you could easily raycast through a 3D Perlin Noise field, and that’s sometimes done in computer games and CGI to simulate clouds, fog and other volumetric effects that can be made to interact realistically with the camera and scene geometry.

a|x


#328

toneburst> I still don’t honestly see the point in moving across the noise field in anything other than a straight line, though.

The use-case I described was using two (or more) lines traversing the map. As have both concluded, if those two lines are parallel and in close proximity, the value series read by each line will be quite similar and highly cross-correlated, because they will be traverse similar, but not identical terrain. Move the lines further apart and the similarity (serial cross-correlation) between them drops off. OK, so how would you produce two channels in which the similarity between them varied in time? Well, one reading line could be straight, and the other could be a sinusoid (or other shape) curvy line that periodically comes close or crosses the straight line. If you look at the time-series of values read by a curve from a Perlin map, and the values read by a straight line, each in isolation, I agree, they will be indistinguishable. But if you look at the their mutual similarity with each other at each point in time, well, that’s a function of their distance from each other at that point, and if you want that distance between them to vary over time in a cyclical way, then one of the reading lines must not be straight.

toneburst> Your use of the term ‘degenerate’, implies to the lay reader a somewhat arbitrary value-judgement (though in sure it wasn’t intended that way).

Sorry, it was mathematical jargon - no disrespect or value-judgement intended. 1D Perlin noise is degenerate because, as Olivier pointed out, you don’t need to go through the whole Perlin algorithm to generate it - there are easier ways.


#329

toneburst> How about having additional controls to control the amplitude of, say, 2 additional octaves of noise. The two additional octaves would share the same start coordinates and offset, and their scale along the X axis would be (fixed or adjustable) multiples or divisions of the ‘base’ octave X scale.

Have a look at the explanation of persistence here. You could just have a single control for persistence that allows the “roughness” to be varied using as many octaves as you like. If persistence is zero, then you only get the single base octave.


#330

toneburst> Here’s an example of something I did using GLSL some years ago: https://vimeo.com/987514

Looks like a non-Newtonian fluid on a loudspeaker. I really need to get my eldest son interested in this visualisation/3D rendering/raytracing stuff (he’s doing a combine CompSci and Fine Arts degree).


#331

@BennelongBicyclist I used to use an Apple application called Quartz Composer. It’s a node-based editing environment for GPU-accelerated realtime graphics and effects. I can highly recommend it, though Apple haven’t developed it much for some years now, sadly.

It’s free, and comes with the Apple Developer Tools package. Apple-only, though.

Also, Processing is used extensively for data-visualisation work. Your son probably already used Processing, anyway.

a|x


#332

Is DMC updated yet just off topic for a sec…lol


#333

No, not yet, too busy discussing Perlin noise here… I promise I’ll set aside time next weekend (not this weekend) to finish v0.8. I’ve got some untested v0.8 changes in my local repository, but I want to add a few more things, including some more byte beats equations (I have already selected and tested them), and two or three types of semi-random / chaotic modulation voltages (already have code for those running), and a better type of random for the random drums. However, since I’ve started collaborating on enhanced firmware for a different module, which has a much richer UI, I’m much less enthused about shoe-horning more and more stuff into DMC, given its very limited (by design) interface, so I think I will called it complete in the near future (others can extend it further if they wish, of course). But polishing what’s already there is important.


#334

I can totally dig why you wouldn’t want to cram any more far fetched stuff but I do think that a trigger pattern generator, Euclidean or otherwise, would be a very logics and great addition to DMC.


#335

@Flohr, yes, there is the beginning of a Euclidean generator mode in my local repo, based on code from the Rebel Tech Στοιχεῖα GPLed implementation of the Bjorklund algorithm

The idea is that a channel of Peaks will act as as a single channel Euclidean generator, which can be patched into the other channel of the same Peaks in a percussion mode - or of course both channels can be used as Euclidean sequencers for other modules. No promises, but Golumb rulers might also be possible - these are the opposite of a Euclidean generator (and are found in the ADDAC402 module).


#336

@BennelongBicyclist sounds excellent! And a good fit for Peaks limited UI, too.

a|x


#337

@BennelongBicyclist sounds great. Very interested in O + C as well. Seems like a great interface for some of your more complex ideas and developments off of Olivier’s work.


#338

Having worked on various apps for O+C, I now shudder at the thought of going back to work on DMC, because the UI is so constrained. But I will add a few of the things mentioned above - definitely the “Euclidean trigger filters”, as implemented in the Piqued app in O+C will be ported across to DMC. I’m a bit more enthusiastic about going back to work on BitT for Braids, because it has a display and encoder, although very constrained after the lovely OLED in O+C. But I am now convinced that being able to set up a complex module just as you like it, via display and encoder, then use it that way in a patch or patches, and then transform it via settings into something else for a different patch, is a viable path out of the ever-expanding rack and endless module acquisition morass. O+C is just a first step toward such a goal - but a fun and useful one, we hope.


#339

Thank you for all the effort you’ve put and continue to put into DMC. Even with the constrained UI, it’s opened up the module for me in some very creative and enjoyable ways.


#340

Went back to the DMC PLL after a long hiatus. It’s actually really sweet. I think precisely because it doesn’t track perfectly. The slew combined with the internal shape mod that you added brings out a ton of cool timbres. Mixing it in with the oscillator its synced to sounds great, but also using the PLL to FM or AM that oscillator. I’m planning on spending some time with DMC PLL and Warps. Awhile back I think I reported some apparent bugs. What I figured out tonight is that it won’t catch on unless you are sequencing the main oscillator. When I just plugged a droning vco into the trigger input it would start to oscillate, but the 1st knob wouldn’t have any effect. Once I started my sequence it worked correctly. There also seems to be some strange relationship between the two channels.