[BUG] Irrational cycling envelope behaviour on (not yet) attached patch

Freak MiniFreak
#1

I have a very strange bug, which I can’t really grasp yet, in connection with the creation of a patch (still in progress):

The cycling envelope affects some parameters. In my case, however, the envelope changes values very quickly at certain times (despite a value of 75 on Rise and on Fall) (you can see this quite well on the LED once you have looked at it and analysed it), resulting in a very shrill sound. You can verify that I’m right by deleting the patch point in the matrix between CycleEnv and Shape1 (which I have on Assign1). Then the shrill sounds no longer occur, but of course this is not a solution. The LED of the CycleEnv flickers at this point (if you can say that at all, because I haven’t really been able to pinpoint it yet, but it seems to occur periodically, more or less). However, if I route the Cycling Envelope to Pitch1+2 with a high value (so that the pitch would have to fluctuate strongly with the “occurring disturbance”) and turn down Assign1/Shape1, the faulty behaviour does not occur.

Creating a new patch with fewer patch points but more or less the same values has unfortunately not yet led to success. Curiously, this does not occur in the MiniFreak-V version either. But as I said, not in other patches either, so this could also be a broken patch or something?

Creating a new patch with fewer patch points but more or less the same values has unfortunately not yet led to success. Curiously, this does not occur in the MiniFreak-V version either. But as I said, not in other patches either, so this could also be a broken patch or something?

To summarise: The cycling envelope behaves strangely in this patch, and only here. Is this also the case for you?

That’s why I’m attaching it here and would be happy if someone could see if this happens to them (unzip, transfer the patch to the device using MiniFreak-V and play it, then you might be able to figure it out).

Addendum 1:
If I now establish a connection between Envelope and Assign1/Shape1 with a value of 15.0, the error does not seem to occur either. It must be an overflow or something similar somewhere. (The bug is driving me slightly crazy).

Addendum 2:
Currently I am not allowed to upload the patch, I will do that as soon as possible.

#2

Added attachment with the according (unfinished!) patch.

MiniFreak_Preset_Formantas WLT_20240311_14h47.mnfx (57.2 KB)

#3

Hi @PhonicGate ,

I don’t have the hardware. But you have the Rise and Fall parametrs modulated by the CYC ENV it self and by LFO 1.
The Rise parameter is modulated with the values -15 from the CYC ENV and with 10 from the LFO 1.
The Fall parameter is modulated with the values 15 from the CYC ENV and with -10 from the LFO 1.
The LFO and the CYC ENV is not synced and run in different tempi. The Rise and Fall parameters is set to the values 74 and 75.
All this result is constantly changing and different modulations of the CYC ENV Rise and Fall parameters. Also in the software version.
Remove the modulations from the CYC ENV Rise and Fall parameters, if you don’t need the tempo changes.

#4

Rise and fall of the cyclic envelope are modulated on purpose, that’s not the real problem. As already described in the opening post, sporadic noise occurs, which does not occur in this form in the MicroFreak-V version (although the behaviour should be the same).

Thanks for trying to help, but I think I understand the machine quite well :wink:

#5

@LBH
And by the way: rise and fall are modulated on purpose, since the existence of the modulation matrix is exactly this case. All of the above should simply work. Looking at the values the should not even be any problems with limit values (0, 100 and so on).

#6

Hi @PhonicGate ,

I’ve simply said, that when you modulate this way, then that give random tempo changes. As far as i recall, then there was no tempo changes, if i removed all modulations of rise and fall.
You may still think there is a bug.

I’ve not adressed the noise you mention in this thread. As far as i recall i did that in another of your topics.

Anyway - I can suggest you contact Arturia technical support, if you want an response from Arturia about this. I’m a user like you. I’m a moderator but i’m not an Arturia employee.

#7

@LBH
I have of course contacted the support team, but apart from the occasional e-mail, they don’t do as much as I would like. I didn’t realize about the affiliation, I thought you were from Arturia.

The problem can be recreated much more easily if the parameters Rise and Fall of the cyclic envelope are set shorter, and of course you are not entirely wrong with your statement. However, I still think it’s a misconception, which is exactly what works in every modular. Of course, the problem here, as I have now realized, is that the LFO continuously changes the Rise and Fall values. However, this is also a bit stupid because, on the one hand, both are digital and, on the other hand, any patch points can be created. If you were to buffer the LFO value and use the last saved value at the start of the envelope cycle, there would be no problem and the desired behaviour still possible.

After all, why is it possible to declare rise and fall as a modulation target if it doesn’t work or works so badly? Why should it be possible to modulate both and not be able to change values with them?

#8

I mentioned that in my first mail.

About using multiple modulations sources for the same parameter.
If two modulations sources for example add a straight line and a triangle wave, then the result will be a blend where those sources both add modulation. That’s quite normal in traditionel modulation matrixes.

Pigments have sidechain options. Then one modulation can be sidechained by another without adding to the total maximum modulation amount. Pigments also have the Combinate modules to blend modulation sources.
I’m not sure, if it’s something like that, you are looking for in MiniFreak.

EDIT: Other Arturia software instruments can have Modulation Mixers.

I think the modulations work as intended in MiniFreak. But perhaps not as you would like it to work.EDIT END.

#9

This is precisely the task of the modulation matrix, so perhaps not the crossfading, but that’s not the problem here.

I’m currently working on a patch that will prove this, as the manual for the device states “The other envelope on the MiniFreak is the Cycling Envelope. It can work as a traditional
envelope, but also has the capability of working in ways that almost make it a kind of LFO.”. And unfortunately that’s not true, not only for this patch, because I can use one LFO to modulate the other, which in turn modulates parameters, whereas it doesn’t work with the cyclic envelope here.

#10

The patch is finished and this is definitly more than just a problem with the cycling envelope since it only happens with some oscillators as the second oscillator and not in single oscillator or paraphony mode. I would call this A BIG FAT UGLY BUG.

More infos plus the according patch after some tests with the MicroFreak V application tomorrow.

#11

I took care of the bug and created a test patch (attached here). The patch includes “CEnv” in the name because the original assumption was that it was a bug in the envelope, but it seems to be much bigger. If anyone wants to reproduce this (on hardware!), here are some steps:

  1. I’m still not 100% sure whether it’s a hardware or firmware error. If it is a hardware error, the device is dead to me, despite the considerable amount of time already spent on creating patches, as it is already a replacement device anyway. However, I believe it is more likely to be a significant firmware bug. The firmware version is 2.0.0.1478.
  2. The patch is set up in such a way that both “Cyclic Envelope” and LFO1 modulate themselves, at the same time generating modulations on oscillators 1+2.
  3. The modulation depths for “Cyclic Envelope” and LFO1 can be controlled via the Macro1 and Macro2 strips, below or 0 means no modulation.
  4. Some oscillators are much more affected than others, and the error manifests itself in crackling and creaking noises. In addition, the LED responsible for the blue illumination of “Save/Panel” flickers very strongly. (I assume that it is this one, but it is difficult to tell, it could also be the other one).
  5. The oscillators most clearly affected are (this is where it can be heard most quickly and clearly): FM/RM (very extreme, making the device unusable as one of the more important oscillators), Harmo, VAnalog, Chords
  6. The error does not occur in the software version “MicroFreak V”.

A very good procedure for determining whether the error occurs:

  1. Connect MiniFreak to the computer via USB and start the “MiniFreak V” software, connect both via the menu item “Audio MIDI Settings”, ensure audio output from V, ensure audio output from hardware device via other way.
  2. Switch on MiniFreak and adjust the volumes of the two sources so that both are clearly audible.
  3. Oscillator2 of the patch uses FM/RM, so it should be audible from the outset. However, you can also select other oscillators and adjust the oscillator parameters accordingly.
  4. The modulation depths for LFO1 and/or cyclic envelope are controlled via the two macro strips, the noise can be heard in the hardware version but not in the software.

In case anyone else wants to argue, which has already happened, that you simply shouldn’t modulate the modulator with itself: But that is exactly what is possible in the modulation matrix. So it has to work, otherwise it is a serious error.

MiniFreak_Preset_BugTest CEnv_20240417_11h51.mnfx (57.1 KB)

#12

Appendix to the last post:

  1. The error occurs in some cases even if the modulation depth entered via the macro strips has the value 0 (which means no modulation).
#13

I have simply stated that you did this. Not that you could’nt or should’nt. It’s possible, and it work. At least in the software i can test.

I have no idea, why you have issues using the hardware but not when using the software.

#14

@LBH
That’s why I did not mention you personally in my post, right? (Meaning: this was not addressed at you at all, but at any possible future commentor.)

I bought the hardware TO USE the hardware, right? Good.