|
|
Post by humpink on Sept 2, 2021 19:39:41 GMT
Hi,
just wondering, is there some kind of internal modulation of the pitch?
At least with my unit, the pitch always wanders around a little bit, like there is some kind of small randomization build in?
Some further explanation:
i am running a vco into the left input, and the left output goes straight to the 4 i/o.
No further patching. Then i adjust density and size until i hear some grains.
Now, every time a grain is played, it has a different pitch which randomly drifts a couple of notes around the pitch set by the pitch knob.
Edit:
Just measured the voltages on the pitch pot and on the two pitch cv inputs.
They all seem to be stable. ( Voltage at the center pin of the pitch pot corresponds to the set value and is stable, Voltage at the pitch cv inputs is not 0 but 1.186 for v/oct pitch cv and 2.377 for pitch cv.)
Already owned a supercell (which shares the firmware with cirrus?) and the pitch problem didn't occur there, the pitch doesn't jump around like on my cirrus.
Thanks and best regards,
Matthias
|
|
|
|
Post by robertlanger on Sept 3, 2021 10:15:44 GMT
I know this behaviour, but the drift is only a few cents, not a couple of notes. A small drift makes sense IMO, to keep the crain cloud moving, not so static.
But your comparison with supercell tells another story - I use the supercell/microcell firmware without modifications. I will check this!
|
|
|
|
Post by humpink on Sept 3, 2021 11:59:10 GMT
Hm, maybe it has something to do with the missing aux input wich is used to modulate all parameters when the internal random modulation is disabled? Already tried to disable the internal modulation like described in the supercell manual: grayscale.info/manuals/Grayscale_Supercell_manual.pdfBut that has no effect at all. |
|
|
|
Post by mrkoggs on Sept 9, 2021 18:52:13 GMT
I seem to be experiencing the same issue. Sounds like some modulation has been applied to the pitch
|
|
|
|
Post by keurslagerkurt on Sept 9, 2021 21:03:03 GMT
I can hear some drift, but don't think it spans 'multiple' notes for me. Felt like a natural amount of movement in the Clouds, but of course i have nothing to compare to!
Maybe it would be a good idea to come up with some kind of repeatable/standardized test strategy?
|
|
|
|
Post by tIB on Sept 10, 2021 9:34:14 GMT
I tried the same as the OP describes and get the same - it's definitely semitones as opposed to cents. I guess next step is to figure if there is a way (with this version) to disable the internal modulation?
|
|
|
|
Post by mrkoggs on Sept 10, 2021 15:37:45 GMT
Untitled.mp4 (2.39 MB) Made a little demo for reference. Had to compress the hell out of it to get it under 3mb but hopefully its clear enough 
|
|
|
|
Post by running in on Sept 10, 2021 20:00:35 GMT
Same issue for me, not just pitch but grain size shape and the rest as well. The grain rhythms change randomly, got to be internal modulation.
|
|
|
|
Post by tIB on Sept 10, 2021 21:26:28 GMT
Yeah, I think that issue as such has something to do with the code to do with the (not available) aux in and that the disabling doesn't work as on the supercell.
Just for balance I should add I've had an incredible time getting to know the cirrus today - it's batshit crazy! Internal modulation or not I am pleased!
|
|
|
|
Post by mrkoggs on Sept 11, 2021 7:49:10 GMT
Just for balance I should add I've had an incredible time getting to know the cirrus today - it's batshit crazy! Internal modulation or not I am pleased! Second this. Its far exceeded my expectations. Granular synthesis is the reason I got interested in modular to begin with but it always seemed like I would have to sell a kidney to access it. So I can't thank you enough Robert for bringing it to the masses! |
|
|
|
Post by funbun on Sept 14, 2021 22:01:20 GMT
Man, might have to get on on the next batch despite the increase in hip prices.
|
|
emptyvessel
New Member
Minimum Viable Fidelity
Posts: 2
|
Post by emptyvessel on Oct 13, 2021 23:56:25 GMT
I'm also hearing semitone levels of variation with mine, it sounds like without the attenuverters which are present on the Supercell we have been left with a small amount of the internal random modulation assigned to more than one of the CV destinations and no way to turn it down. Also tried the "press both mutes" shortcut with no effect. Hopefully something can be done to set the default internal mod to zero, to my ears the amount of pitch modulation is discordant in most cases. Otherwise loving the module, a great addition to the lineup and a nice way to stereoise the mono signal before output. Cheers. Greg emptyvessel |
|
|
|
Post by funbun on Oct 14, 2021 13:59:00 GMT
Has there been any resolution to this issue?
|
|
|
|
Post by tIB on Oct 14, 2021 15:28:26 GMT
Has there been any resolution to this issue? Nope - think Robert got tied up with superbooth when the issue was first picked up. It's not a deal-breaker by any means but I increasingly find times when I wish it wasn't the case/could be disabled. |
|
|
|
Post by mrkoggs on Nov 1, 2021 18:34:33 GMT
Does anyone know if the Cirrus firmware can be updated via the audio-in like the original Clouds? I have a pretty limited experience with the C language but I would be up for looking into fixing this if its possible. Gotta say its a shame to not be able to use the module for anything harmonic  |
|
|
|
Post by thehatghost on Dec 28, 2021 20:15:00 GMT
So... I just tried to load the original supercell core firmware from the Grayscale website to my Cirrus and ... Success! I followed the directions in the supercell user manual and it worked.
Also just tried to re-upload the super-parasites firmware and it also worked.
I've been looking at the code a bit ( github.com/patrickdowling/superparasites), and while it's super complicated and my c skills are lacking I'm thinking that the code in superparasites/supercell/dsp/random_oscillator.h probably control the random oscillations.
Could the oscillations be tured off by changing the following line:
next_value_ = Random::GetFloat() * 2.0f - 1.0f;
to something like
next_value_= 0.0f ?
Looking at the circuit diagrams it appears that the main chip generates the random cv and sends it to another chip which I'm guessing looks for cv or aux in and if it doesn't find it then applies the random cv generated by the main chip.
How to change and compile the software to a wav file is beyond my skill set, but maybe any of you c wizards out there could give it a try?
I'm also starting to thing that the audio output on the super-parasites is lowered in the software with the assumption that the audio out would go through the built in VCA on the eurorack version. I think this takes place in the code at superparasites/supercell/cv_scaler.cc lines 166-170.
|
|
|
|
Post by dizzeesatchel on Dec 29, 2021 12:46:24 GMT
Excellent detective work! I'm no C wizard unfortunately but this sounds very promising. Thank you for being bold enough to try this out with your own Cirrus  |
|
|
|
Post by rockysmalls on Dec 29, 2021 14:17:25 GMT
this will be SO excellent if a new audio file firmware could be made with some options or just “off” for those randomisers.. not that i mind them but it’s clearly something that gets in the way of more ‘controlled’ tonal use of this amazing module..
|
|
|
|
Post by tIB on Dec 29, 2021 15:53:59 GMT
this will be SO excellent if a new audio file firmware could be made with some options or just “off” for those randomisers.. not that i mind them but it’s clearly something that gets in the way of more ‘controlled’ tonal use of this amazing module.. This! Come on you C wizards... in an ideal world the on/off by pressing the two buttons would work as should. The best of both worlds is always the best! |
|
|
|
Post by robertlanger on Dec 29, 2021 18:33:05 GMT
So... I just tried to load the original supercell core firmware from the Grayscale website to my Cirrus and ... Success! I followed the directions in the supercell user manual and it worked. Wow, that sounds good! We are investigating the issue intensely since a while and it looks mysterious at some points... Thanks for your engagement! ❤️🙏❤️ |
|
|
|
Post by mrkoggs on Dec 30, 2021 18:06:35 GMT
Nice work thehatghost! I'm also definitely not a C wizard but just looking through the super-parasites firmware it looks like it might be related to line 50 in "settings.cc": data_.state.random_rate = 0.5f;I'm not sure if the random_oscillator.h is the culprit because its only being imported into Oliverb.h Is this the exact firmware that is running on the Cirrus? Because it looks like the switch case for stopping and starting the random modulation is present at line 404 (how appropriate!  ) but obviously its not working as it should: case SWITCH_MUTE_OUT:
{
if (e.data < kLongPressDuration) {
bool mute_state = processor_->mute_out();
processor_->set_mute_out(!mute_state);
} else if (e.data >= kVeryLongPressDuration) {
if (switches_.pressed(SWITCH_MUTE_IN)) {
bool dac_state = dac_.is_generating_noise();
if (dac_state) {
dac_.StopNoise();
} else {
dac_.StartNoise();
}
SaveState();
}
}
}
break;
Also, does anyone with actual supercell experience know, does holding the "bank" button down and adjusting the pan knob modify the internal modulation level? Looks like this is the case in the in "ui.cc" although some of the code has been commented out |
|
|
|
Post by thehatghost on Dec 30, 2021 18:46:00 GMT
Nice work thehatghost ! I'm also definitely not a C wizard but just looking through the super-parasites firmware it looks like it might be related to line 50 in "settings.cc": data_.state.random_rate = 0.5f;I'm not sure if the random_oscillator.h is the culprit because its only being imported into Oliverb.h I think you're right! I tried to find where random_oscillator.h was called but couldn't find it, but as its being called by oliverb.h it's probably related to the pitch shifting reverb settings which makes a lot more sense.
I did try to update the cirrus with the microcell firmware, which after digging through the mod wiggler forums is supposed to have the random oscillations turned off by default. After some testing it seems like even if they are off by default in the firmware they are on in the cirrus. Also tried hitting the mute switches to no avail. Nice work on isolating the switching code, which seems quite straightforward. Maybe a fix lies in using a different switching mechanism to call the stop noise and start noise functions? Or maybe the mute pins are physically disconnected from the processor and the mute is an analogue vs a digital function?
Edit - just checked the mute button hardware and except for some weird solder pads next to each they work as expected connected to the main chip.
On the hardware side the best I can understand it looks like the processor has two pins which monitor the mute buttons, and another which generates the digital mod cv out which goes into a DAC and then out to the inputs. So possibly the random CV is generated digitally by the processor then converted to analog then applied to the inputs and then converted from analog back to digital and read once again by the processor?
I AM toying with the idea of disconnecting the digital trace between the processor and the DAC for the noise and just throwing a physical switch in...
Edit: I was looking at the chip wrong - what i was looking at what the analogue multiplexer going into the ADC
|
|
|
|
Post by tIB on Dec 30, 2021 23:41:15 GMT
Nice work thehatghost ! I'm also definitely not a C wizard but just looking through the super-parasites firmware it looks like it might be related to line 50 in "settings.cc": data_.state.random_rate = 0.5f;I'm not sure if the random_oscillator.h is the culprit because its only being imported into Oliverb.h I think you're right! I tried to find where random_oscillator.h was called but couldn't find it, but as its being called by oliverb.h it's probably related to the pitch shifting reverb settings which makes a lot more sense.
I did try to update the cirrus with the microcell firmware, which after digging through the mod wiggler forums is supposed to have the random oscillations turned off by default. After some testing it seems like even if they are off by default in the firmware they are on in the cirrus. Also tried hitting the mute switches to no avail. Nice work on isolating the switching code, which seems quite straightforward. Maybe a fix lies in using a different switching mechanism to call the stop noise and start noise functions? Or maybe the mute pins are physically disconnected from the processor and the mute is an analogue vs a digital function?
Edit - just checked the mute button hardware and except for some weird solder pads next to each they work as expected connected to the main chip.
On the hardware side the best I can understand it looks like the processor has two pins which monitor the mute buttons, and another which generates the digital mod cv out which goes into a DAC and then out to the inputs. So possibly the random CV is generated digitally by the processor then converted to analog then applied to the inputs and then converted from analog back to digital and read once again by the processor?
I AM toying with the idea of disconnecting the digital trace between the processor and the DAC for the noise and just throwing a physical switch in...
Edit: I was looking at the chip wrong - what i was looking at what the analogue multiplexer going into the ADC
Given my complete lack of experience/knowledge here take this with a huge pinch of salt but... could it be something as simple as debounce? |
|
|
|
Post by thehatghost on Dec 31, 2021 22:22:05 GMT
So... While poking around the Cirrus circuit board today I thought I almost had it by disconnecting one of the pins from the processor, but then the issue persisted and while poking around the board I fried it... 
What I learned:
1. My focus on solving a problem sometimes overrules my better judgement.
2. Pin 29 does create random CV which i confirmed with both the meter module and by ear directing the pin to the cv input of an oscillator. This is the pin that is specified in the microcell schematic as the "aux internal_mod_raw" after severing the pin with a knife the random cv still continued... so i'm guessing all the software controls are controlling the output of pin 29 but the random cv is coming from elsewhere.
3. See #1.
I guess that's why it's called Abused Electronics? At least now I can just relax and until the original version of clouds for AE comes out  . |
|
tgergo
Junior Member
Posts: 59
|
Post by tgergo on Dec 31, 2021 23:43:20 GMT
So... While poking around the Cirrus circuit board today I thought I almost had it by disconnecting one of the pins from the processor, but then the issue persisted and while poking around the board I fried it... What I learned: 1. My focus on solving a problem sometimes overrules my better judgement.
2. Pin 29 does create random CV which i confirmed with both the meter module and by ear directing the pin to the cv input of an oscillator. This is the pin that is specified in the microcell schematic as the "aux internal_mod_raw" after severing the pin with a knife the random cv still continued... so i'm guessing all the software controls are controlling the output of pin 29 but the random cv is coming from elsewhere. 3. See #1.
I guess that's why it's called Abused Electronics? At least now I can just relax and until the original version of clouds for AE comes out . Wow, I don't have the Cirrus yet, but thank you for your sacrifice. |
|
) but obviously its not working as it should:
.