I face a strange behaviour of the X term in 10.38 and after some research can’t find any other explanation than a bug.
In the attached preset, the X term of formula A doesn’t return the expected value. It is configured in Result proportionnal to Octave mode, quantized by semitones and it should return 0 on C4, 1 on C#4, 2 on D4 and so on.
First question, does it work the same way on your configurations? Or is it ok?
This preset is an isolation of the problem. The original preset is made with much more formulas and patch points and I created it over several days. I’m pretty sure the problem appeared on the last moments of the creation process. So I was wondering, may it be related to the save/load/archive problem I’ve mentionned in another topic? Does the preset may have been corrupted in antoher way when saving, making it readable but acting weird?
Yes your preset seems corrupted somehow. Of course, you would never use it this way as you need to use nn to convert the note number to KHz the Frequency needs. But it should work as you note and it does if you start with an empty preset. I assume you have Christophe’s tool as you are using an additive bank. Did you use that first perhaps? Maybe something got corrupted that way (what version of his tool are you using?).
By the way, it’s not an Oct mode issue I think. X is just corrupted it seems as normal KHz mode does not work as expected either.
Thanks Richard for your answer.
Yes, the idea behind this formula is to read a graph and link each semitone to a slider. Then using nn, the graph lets me choose a different frequency for each semitone.
The goal is to create an overlay which allows to use the Continuum surface as some kind of drum pad playing on each semitone a different analysis at a different frequency, with a different speed/pan/length etc…
I’m not far from it but you’re probably right. I may have corrupted the preset myself with my Max/MSP overlay.
I only used Christophe’s tool to create the analysis so it’s not likely that he’s responsible for that.
I thought I’d publish it here for testing but I’ll have to re-write the preset before that. Then I’ll post it as soon as possible
OK. So with 40 possible slots you can certainly have plenty of options for using Continuum as a percussion pad using a note value 0-39 as index into the set (or whatever set range you choose). You could then also use a stepped Y to get three possible pitches per pad or a continuous pitch pitch change as you move up Y.
Actually, I use the 3 graphs on 24 semitones. With the appropriate formulas, each graph can control 2 parameters for each semitone (the 24 first sliders control 1 parameter, the 24 last another parameter). So 6 parameters in total.
As Y is less accurate, especially for quick hits, I will mostly use it to add randomness or slight changes. Nothing I need precision on.
I re-write the preset and post it here with the overlay
Interesting! I’d like to see that. 10.40 should be available soon for new Continuum users. Maybe that fixes some of these corruption issues. That file you posted makes any X formula used give wrong output. Very strange.
Here’s my Batterie x16 re-written. It works fine and indeed, this is my Max/MSP overlay that seems to corrupt the patch. I don’t know how but I know for now I must not save anything in the patch after using the overlay.
Just a quick explanation as it is not a classic use of the Continuum.
The first idea is to use the Continuum as a drum pad. I’ve been developing and practicing this “instrument” since 2 or 3 years and, over time, I ended up choosing this spliting :
E/F and B/C (the largest “white” keys) for Kick
F# to Bb for HiHat when hit softly
with F# and Bb for opened HiHat / G > A for closed HiHat
G > A for Snare when hit more deeply.
You can see on social media some video of how I play it.
And with the arrival of Loris and the generosity of Christophe, I had the opportunity to try and mix usual drum synthesis with it. And it can clearly lead to beautiful, rich and complex drum sounds.
In the folder, you can use the EM .mid file, it works (v102). In this patch, I use octaves C4 to C6 with the previous drum sounds allocation. And you can use graph 1 to 3 to change on each semitone in those 2 octaves :
the analysis index
start in this index
frequency
length of “reading”
sFrequency
Pan from L to R
Use the png images to get some marks
And you’re welcome to open the Max Overlay (v100) but I don’t recommend to use it unfortunately. It clearly messes up the patch for now. But you will have a good idea of where I want to take it.
Hope it’s not inappropriate to share this kind of things here. Batterie x16.zip (67.7 KB)
Ah - I see you are creating your own drums and mixing in the additive banks you loaded and control with that graphing interface. Very inventive. No one has used graphs like this before. Graphs are the great untapped element in EaganMatrix.
Also if you look at those Overlays by Ed, he does not save the preset for each configuration. He saves preset configurations in a .JSON file that he loads and you select your preset configurations from that. A better approach than trying to save the preset with a different configuration each time you then have to keep track of.
It might be interesting to attempt to come up with a standard format for overlay synths. You couldn’t cover the entire design space, but I’m guessing a large swath of overlay presets could be captured this way. Then one could build a design application that can export definitions, and then have a variety of runtimes that could read those definitions and display these little synths in a DAW plugin, computer standalone, and mobile apps.
The whole idea of them is that anyone can use whatever tools they want to create something. I don’t want to have to write in some language or use tools I don’t care about for a machine I don’t have. For example, I have no desire at all to do anything in MAXMSP. But if there was a generic library (or set of them for different environments) that could be used, that could be interesting. So some underlying standard might be useful that could easily be ported to different environments. But remember the overlay preset itself is EaganMatrix. Until some AI tool can actually create the presets that part is very manually driven. What would be useful is a tool that can parse the preset and create an interface for the macros and pokes perhaps, but even that would be difficult to create a functional interface for (versus a simple list of macros attached to what components, etc.)
Of course to write overlays you really only need a few things in addition to standard Midi support 1) Ability to read and write 14-bit CCs 2) Ability to create Pokes and 3) Ability to read and write EaganMatrix (poly AT) streams. Having libraries available to do that for different environments is important.
Thanks Richard! Indeed, I’m quite glad I had the idea of using the graphs this way. But I clearly need to review my overlay stream communication.
I was indeed inspired by the way Ed saves the configuration of the Overlay GUI and not the preset itself. But it’s not so simple to organize the Max patch so that everything works. Ed seems to have a lot of experience with that. As for me, I’m just tinkering.
Regarding what you mentioned, Paul (if I understand correctly), I would say that on Max/MSP, what could be interesting would be to code objects that format messages for the EaganMatrix. Then, it would almost only require connecting GUI elements for it to work. However, this requires coding knowledge that I don’t have.
To get back to the main topic of this thread, indeed, I’m waiting to see if version 10.40 solves the problem. My slight concern is that it’s not a clear-cut bug that happens every time. Hope Lippold will clearly identify the cause of it
MAXMSP is so convoluted in its interface it may be difficult to find the issue here. Maybe Lippold has tools to look at your simple .mid file and tell what is causing the X corruption. Some of Paul’s ideas really might be useful if for example we isolate a tool for creating Overlays that a number of people might center on. To write overlays you need a number of things IMHO.
The Overlay preset design
Overlay preset implementation (and initial testing you can do in editor)
Overlay preset interface definition so you can easily write your overlay - what to all the macros you use do and what pokes are required, etc.
Midi/Overlay library - Support for 14 bit CCs, Normal CCs, Pokes, EaganMatrix Streams, real time capture of incoming midi streams for your device, etc.
Overlay application code
GUI interface for overlay (which might be integrated in the code itself)
Documentation on using the Overlay
Platform development environments (creating for PC, MAC, Electra One, etc. - creating apps vs plugins, etc.)
The bottom line is that there likely will not be that many people creating overlays for the community as it requires a lot of skills, not to mention time. So maybe trying to center on a toolset where a group of people can create all the interfaces required to easily reproduce overlays is not such a bad idea. An Overlay builder would be an interesting project, but the community is too small to make putting in the amount of time required to do that worthwhile IMHO.