Will there be a new M:C update?

[Billy1992]

You know that a wavetable can be build on the base of any synthesis ?
So, saying a wavetable sounds like a wavetable on its own doesn’t make so much sense…
I’m not saying that I don’t want to see machine as syn bits on M:C (I would love and I agree that it would expand the sonic possibilities) but I think that :
1.Syn Bits as it is designed on Syntakt would make no sense of M:C
2.It would make no sense based on the marketing made to sell the M:C

But I’ve already said this, and don’t want to argue more
Have a nice day

[chuchu]

It says it utilises the 4 FM operators as in, it’s a 4 oscillators wavetable synthesis.

It’s not FM at all, you can check on ess q&a m:c thread he specifically talks about that.

[Billy1992]

Technically, it’s this algorithm used (without feedback on op 4) so no frequency modulation on itself BUT it’s an algorithm frequently used on FM synths so I would consider it as FM synthesis. The particularity on chord machine is that every operator share a wavetable (thing that we can see on other fm synths too )

[chuchu]

It’s FM but it doesn’t use FM, so it’s not FM.

It’s 4 oscillators which play the same wavetable there is no operator no ratio no feedback it’s as close to FM as any other wavetable synths.

I’m not aware of any FM synth that allow you to synchronize 4 operators while sweeping through their wavetable and having them detuned to create inversions/different interval mix in chords created by the operators.

Would love if you could link me any FM synth that does that.

[bibenu]

FWIW I offered FM as an example of something that might lock in the architecture, I didn’t make a definitive statement about FM and I didn’t say FM was the only aspect where the architecture might be locked in.

@bibenu

For instance the design/architecture might be so locked into FM

Turns out (I didn’t know) Ess is saying something similar (but with insider knowledge I didn’t have)

@chuchu

ESS did answer a lot of questions on the m:c and what could realistically be added to it and he never said that adding machines was impossible, just that it was a slow and fairly cumbersome process.

@bibenu

It could be difficult to change code, without necessarily being bad code

[chuchu]

@Ess

Also asked by other people)

No plans so far. It is technically possible, but making a machine takes a lot of work from both me and our DSP engineer Oscar who implements it on hardware (in assembler!) … So a lot of time has to be allocated for it and at the moment we want to focus on other things.

Its not a question of locking architecture nor changing the code, he was saying its hard MAKING a machine, syntakt machines are already made and done. Backporting them onto the m:c wouldnt be nearly as complicated as making new machines from the ground up.

On the Chord Machine:

@Ess

Not really, I was just messing around with some ideas. At the time I was obsessed with trying to make all parameters feel ‘smooth’, so I came up with the oscillator balancing thing. At first it was sort of a mix between additive synthesis and chord intervals, but we later as a team made it much more musical by introducing the idea of using chord inversions for the interval mixing.

The voice itself is simple - it’s just four oscillators that each play the same wavetable. I made the waveforms with a max patch which later turned into Hard/Softcore. All of the tables in the Cycles are made strictly with additive synthesis. Sorting them in the particular order took a long time, it was really hard to find an order that felt logical and nice to sweep through, hehe.

I would like to add graphs of all the waveforms in the manual, but I haven’t had the time to plot them out yet.

On the specific structure of the m:c and the 7th machine that got cut:

@Ess

Yes. There were one patch that didn’t make the cut, but it was mostly due to time constraints and its structure being radically different to all the other patches. The system in the Cycles that Oscar (DSP engineer) put in place is quite ingenious. It’s a huge structure that can dynamically change, this is what allows us to swap machine per step. It’s wild!

emphasizing on “a huge structure that can dynamically change”.

On the model:cycles using the same CPU as the digiboxes:

@Ess

The CPU is a Coldfire MCF5441 with up to 385 dhrystone 2.1 MIPS @ 250 MHz … Same one as in our other current lineup of products sans the Octatrack. (But before anyone asks - no that doesn’t mean we can run anything on everything, it’s a general purpose CPU and it does very different things across all machines.)

[bibenu]

@chuchu

Its not a question of […] changing the code,

If you don’t change the model cycles code, you won’t get new model:cycles firmware. New firmware doesn’t happen by magic.

@chuchu

he was saying its hard MAKING a machine, syntakt machines are already made and done. Backporting them onto the m:c wouldnt be nearly as complicated as making new machines from the ground up.

You know enough about the software architecture of the two different firmwares to be sure about that ? I certainly don’t know enough to make a definitive statement (my knowledge of that is zero, like nearly everyone here I would expect).

[chuchu]

Just read Ess quote on the subject? he is talking about “making” a machine.
M:C already had new firmwares updates in the past.

[bibenu]

I did … I see nothing that contradicts what I’ve said

@chuchu

ESS did answer a lot of questions on the m:c and what could realistically be added to it and he never said that adding machines was impossible, just that it was a slow and fairly cumbersome process.

@bibenu

It could be difficult to change code, without necessarily being bad code

[chuchu]

that’s not his quote, his quote is :

@Ess

Also asked by other people)

No plans so far. It is technically possible, but making a machine takes a lot of work from both me and our DSP engineer Oscar who implements it on hardware (in assembler!) … So a lot of time has to be allocated for it and at the moment we want to focus on other things.

Keep in mind that at that time only the m:c had the concept of machines (outside of the older pieces of hardware like the MnM).

[plragde]

This whole thread is like arguing about the deck chairs on the Titanic – as it lies at the bottom of the ocean.

[bibenu]

My suppostion:

@bibenu

It could be difficult to change code, without necessarily being bad code

… and what Ess said …

@Ess

No plans so far. It is technically possible, but making a machine takes a lot of work from both me and our DSP engineer Oscar who implements it on hardware (in assembler!) … So a lot of time has to be allocated for it and at the moment we want to focus on other things.

[chuchu]

He is talking about making a machine from scratch, not backporting existing machines.

that’s what he is talking about when he says it “takes a lot of work” :

@Ess

All DSP is done in assembler. Our process for this project was that first I made prototypes in Max which I made Max4live Devices out of and sent out to all my colleagues. We then collectively tested them and improved the patches based on the feedback received. After we were happy with how they sounded we started translating the patches to run on hardware, and this was quite a long process where I worked closely with our amazing DSP engineer Oscar A who dealt with my stupidity for a few months until we had all of the machines running on hardware. Thanks Oscar!

This process would be different as the prototypes of the syntakt machines are already made and done, the patches are already tested and the feedback is already received. Translating the patches to run on hardware is also already done (since they exist on the syntakt).

The only thing left to do is backporting the said patches onto the m:c.

[bibenu]

My preferred metaphor is more like schrodinger’s cat. One day Elektron may release new M:C firmware and on that day we will know if it’s possible.

Until that day, there’s a probability of it happening and a probability of it not happening. Nothing more.

And we will probably never know if it was easy/difficult/time-consuming/a trivial event.

I’ve not been arguing that it must be hard. I’ve been arguing about the claim that it must be easy, we just don’t know that.

[chuchu]

@bibenu

I’ve not been arguing that it must be hard.

@bibenu

It could be difficult to change code

I mean, have you?

[Fin25]

I don’t know fuck all about anything, but I know you’re all wrong.

[bibenu]

Did you see the word “could” in that sentence you quoted ? That means I was entertaining the possibility it was hard, not arguing it must be hard.

[chuchu]

And I gave you a bunch of quotes that indicate that there is no proof that it could be difficult.

Actually if we’re being factual, the fact that the syntakt was able to get the exact same machines (which sound exactly the same) as the m:c on a seemingly different structure shows that the process of porting existing machines to different hardwares is known and mastered.

Considering that m:c machines were ported to the syntakt, why would the reversed operation be difficult? they use the same CPU.

The shared machines use the exact same parameters, the syntakt even sports the “punch” compressor of the m:c, both products are also strictly monophonic.

The only difference is the m:c can do machine lock (which ess hinted at its structure being able to change dynamically) while the syntakt cannot.

[plragde]

It would have been sensible practice for the software architectures of M:C and Syntakt to be similar enough to ease the porting of machines and other features, and this probably has some beneficial effects on any potential attempt to go in the other direction. But just because something is technically possible doesn’t mean it’s going to get done.

[bibenu]

I agree.