MUFF WIGGLER Forum Index
 FAQ & Terms of UseFAQ & Terms Of Use   Wiggler RadioMW Radio   Muff Wiggler TwitterTwitter   Support the site @ PatreonPatreon 
 SearchSearch   RegisterSign up   Log inLog in 
WIGGLING 'LITE' IN GUEST MODE

intellijel Rainmaker
MUFF WIGGLER Forum Index -> Eurorack Modules Goto page Previous  1, 2, 3 ... , 57, 58, 59  Next [all]
Author intellijel Rainmaker
DabiDabDab
How does this thing not have under its mod destination a time parameter (part of the delay clock subset)?? How is this possible? Ok, its a grid type of tapping system, i get it. But every delay under this sun has a timing knob to stretch the timing between the taps one way or another and even if this thing is not set up in a such a way it could have time routed to the mod matrix. But no.. I dont get, im sorry, it verges on self sabotage from what i can tell, to be perfectly candid with you.
evileye0702
DabiDabDab wrote:
How does this thing not have under its mod destination a time parameter (part of the delay clock subset)?? How is this possible? Ok, its a grid type of tapping system, i get it. But every delay under this sun has a timing knob to stretch the timing between the taps one way or another and even if this thing is not set up in a such a way it could have time routed to the mod matrix. But no.. I dont get, im sorry, it verges on self sabotage from what i can tell, to be perfectly candid with you.


There are multiple mod destinations that affect timing of the delay:

Delay CLK DIV
Grid
Delay Mod Rate
Groove Type


This is all based on the most recent update. I'm not sure if these were in the original firmware or not.
damase
evileye0702 wrote:
DabiDabDab wrote:
How does this thing not have under its mod destination a time parameter (part of the delay clock subset)?? How is this possible? Ok, its a grid type of tapping system, i get it. But every delay under this sun has a timing knob to stretch the timing between the taps one way or another and even if this thing is not set up in a such a way it could have time routed to the mod matrix. But no.. I dont get, im sorry, it verges on self sabotage from what i can tell, to be perfectly candid with you.


There are multiple mod destinations that affect timing of the delay:

Delay CLK DIV
Grid
Delay Mod Rate
Groove Type


This is all based on the most recent update. I'm not sure if these were in the original firmware or not.


Also use the comb filter, the comb size(and cv input) acts as delay time.
orbita
Can you do eventide ultratap style short, clean delays with tapering of the delay times?
cliffemu
orbita
Can you provide an example? Rainmaker has the comb section as well, which is basically a short delay.
starthief
There are different tap "grooves" available including accelerando and ritardando, if that's what you mean by "tapering of the delay times."

Pretty much the only thing you can't do, in terms of multitap, is individually adjust the time for each tap. There are a lot of groove options though.


The same is true on the comb filter side, if you slow it down enough to be audible as delay taps rather than a comb. The selection of patterns is different though, meant more to impart different character to comb filtering than for different rhythms.
orbita
I suspect accelerando and ritardando are the same. I actually meant the spread control which is described as:

Spread also relates to the delay taps, this time adjusting the tap spacing. Values left of centre make the taps more closely spaced at the beginning of the burst, producing a slowing-down effect, whereas clockwise of centre values group taps towards the end of the burst to create a speeding-up effect rather like the sound of a spinning coin coming to rest.

The taper controls the increase/decrease of the volume which also gives a nice effect.

Are these grooves modulatable /morphable so you can move between an accelerating and decelerating repeats to emulate this spread function.

Can these grooves be applied to the pitch shifting too?

Also is there a way to progressively shorten the length of the repeats?

Can taps be reversed?

I don’t want to program individually. I’d like to apply algorithms that can be modulated/played in real-time. Eg apply a ‘randomly reverse taps’ algorithm and then adjust percent that are reversed.

Thanks!


starthief wrote:
There are different tap "grooves" available including accelerando and ritardando, if that's what you mean by "tapering of the delay times."

Pretty much the only thing you can't do, in terms of multitap, is individually adjust the time for each tap. There are a lot of groove options though.


The same is true on the comb filter side, if you slow it down enough to be audible as delay taps rather than a comb. The selection of patterns is different though, meant more to impart different character to comb filtering than for different rhythms.
cliffemu
Look at the manual to see all of the mod a / mod b assignments. These are the things you can modulate externally, besides what’s on the front panel. They include groove type and amount. There’s also an internal time modulator wave. You can externally control the wave type, mod level and mod rate of that, too.

To randomly reverse taps, you have to assign the trigger input to reverse and send random gates to it
starthief
cliffemu wrote:
Look at the manual to see all of the mod a / mod b assignments. These are the things you can modulate externally, besides what’s on the front panel. They include groove type and amount.


I didn't realize groove type was among them too... very cool smile

So far I've never even sent any CV to Mod A or B, just kept them at their defaults (internal LFO rate/amount). It's already a very busy delay without external modulation, and I'm not trying to be Richard Devine lol
scottmfr
DabiDabDab wrote:
How does this thing not have under its mod destination a time parameter (part of the delay clock subset)?? How is this possible? Ok, its a grid type of tapping system, i get it. But every delay under this sun has a timing knob to stretch the timing between the taps one way or another and even if this thing is not set up in a such a way it could have time routed to the mod matrix. But no.. I dont get, im sorry, it verges on self sabotage from what i can tell, to be perfectly candid with you.


There's a new Beta firmware that's in testing right now that allows you to assign Delay Time to Mod B and set the range using Delay CLK DIV on Mod A. This lets you sweep from ultra short to ultra long delays with the sweep of a knob. Very fun. Changing the Groove Type has a pretty big impact on how the texture sounds when you speed it right up.

This firmware also adds a High/Low amount toggle on the Delay time mod and Comb Size Mod Level. Great if you want to dial in some more subtle modulation.

You can download the Beta here: https://forum.intellijel.com/t/rainmaker-1-09-141-beta/1551/7
damase
scottmfr wrote:
DabiDabDab wrote:
How does this thing not have under its mod destination a time parameter (part of the delay clock subset)?? How is this possible? Ok, its a grid type of tapping system, i get it. But every delay under this sun has a timing knob to stretch the timing between the taps one way or another and even if this thing is not set up in a such a way it could have time routed to the mod matrix. But no.. I dont get, im sorry, it verges on self sabotage from what i can tell, to be perfectly candid with you.


There's a new Beta firmware that's in testing right now that allows you to assign Delay Time to Mod B and set the range using Delay CLK DIV on Mod A. This lets you sweep from ultra short to ultra long delays with the sweep of a knob. Very fun. Changing the Groove Type has a pretty big impact on how the texture sounds when you speed it right up.

This firmware also adds a High/Low amount toggle on the Delay time mod and Comb Size Mod Level. Great if you want to dial in some more subtle modulation.

You can download the Beta here: https://forum.intellijel.com/t/rainmaker-1-09-141-beta/1551/7


we're not worthy
The variable delay time will change it up a lot for me, opening it up more as a non clocked delay.

If testing out new features, i want to echo someone else’s request from a long time ago to have a way to ‘dis-include’ certain parameters from the triggered random. There is several options to choose what you would like the random to affect, but the only way to currently disinclude a specific parameter is by leaving it selected with the encoder so that the random doesnt change it.

A common scenario i have to do this for every single time is when randomizing the ‘all comb’, but having the comb modulation level go random makes it a bit wacky for lack of a better word so i always have to set it to 0 and leave it selected and then the comb modulation becomes a really cool glitch effector. Randomizing all delay has very limited use for me because there is a couple pitch related parameters that just blast it off into unusable territory too quick when all of them are random at the same time. A little more control on the randomized parameters would go a long way

Thanks! Glad to hear the user uproar about updating difficulties hasnt turned intellijel away from making improvements
cliffemu
scottmfr
Thanks for sharing the beta firmware link! Those extra parameters will make a big difference for sure.

damase
another way to exclude values from randomization is to assign them to the mod a and b knobs. I like to do this with the comb mod to keep things sane smile
damase
cliffemu wrote:
scottmfr
Thanks for sharing the beta firmware link! Those extra parameters will make a big difference for sure.

damase
another way to exclude values from randomization is to assign them to the mod a and b knobs. I like to do this with the comb mod to keep things sane smile


Oh really? I had no clue it worked like that. Thank you, thats at max 3 parameters to tone down the random a bit, not perfect but it helps
jjclark
orbita wrote:
I suspect accelerando and ritardando are the same. I actually meant the spread control which is described as:

Spread also relates to the delay taps, this time adjusting the tap spacing. Values left of centre make the taps more closely spaced at the beginning of the burst, producing a slowing-down effect, whereas clockwise of centre values group taps towards the end of the burst to create a speeding-up effect rather like the sound of a spinning coin coming to rest.

The taper controls the increase/decrease of the volume which also gives a nice effect.

Are these grooves modulatable /morphable so you can move between an accelerating and decelerating repeats to emulate this spread function.

Can these grooves be applied to the pitch shifting too?

Also is there a way to progressively shorten the length of the repeats?

Can taps be reversed?

I don’t want to program individually. I’d like to apply algorithms that can be modulated/played in real-time. Eg apply a ‘randomly reverse taps’ algorithm and then adjust percent that are reversed.

Thanks!


Some interesting ideas here!
It is very difficult to make additions/changes to the FPGA code at this stage, since it is packed to the limit. I will see what I can do.

The grooves are modulatable, but only between the uniform spread and the selected groove. It might be possible to have the groove amount morph between two selected grooves, which would allow for morphing between the accelerando and ritardando grooves that you are looking for. I suspect that this will make the UI messy, however.

I might be able to get the per-tap reversal to work.

As for speeding/slowing the repeats, you can do this now by using the MOD A/B to control the FB Tap# L&R. This will require some external modules - for example, trigger a drum hit (externally) and at the same time trigger an envelope with minimum attack time and set the decay rate to match the rate at which the repeat will speed up. Feed that input into the MOD cv input.

I am not sure what you mean by applying grooves to the pitch shifting. The individual taps already have pitch shifting on them and thus the timing of the pitch shifts will follow the groove setting.
depaffect
I recently got a Rainmaker! Love it, but there's something confusing happening.

This is purely about the delay section btw, not the comb. Comb is off.

If the delay time is very low (eg 0.0ms - so no delay), a tap that is pitch-shifted will play again ~20 seconds later.

This is with feedback at 0, nothing patched into it except the audio signal.

It doesn't happen if the tap isn't pitch shifted.

Any ideas?

edit - actually i'm getting it in some other patches unaltered. 053 resobeat is an example - i hear a "tap" about 20 seconds after the fact!
Risc_Terilia
evileye0702 wrote:
DabiDabDab wrote:
How does this thing not have under its mod destination a time parameter (part of the delay clock subset)?? How is this possible? Ok, its a grid type of tapping system, i get it. But every delay under this sun has a timing knob to stretch the timing between the taps one way or another and even if this thing is not set up in a such a way it could have time routed to the mod matrix. But no.. I dont get, im sorry, it verges on self sabotage from what i can tell, to be perfectly candid with you.


There are multiple mod destinations that affect timing of the delay:

Delay CLK DIV
Grid
Delay Mod Rate
Groove Type


This is all based on the most recent update. I'm not sure if these were in the original firmware or not.


His post Wed Mar 13, 2019 3:19 am, he never posted again.

You just ended this guys whole MW career

jjclark
depaffect wrote:
I recently got a Rainmaker! Love it, but there's something confusing happening.

This is purely about the delay section btw, not the comb. Comb is off.

If the delay time is very low (eg 0.0ms - so no delay), a tap that is pitch-shifted will play again ~20 seconds later.

This is with feedback at 0, nothing patched into it except the audio signal.

It doesn't happen if the tap isn't pitch shifted.

Any ideas?

edit - actually i'm getting it in some other patches unaltered. 053 resobeat is an example - i hear a "tap" about 20 seconds after the fact!


This is a feature, not a bug! lol

What is happening is that you are trying to peer into the future...
Pitch shifting is done by speeding up the playback from the delay line. If you start out, say at a delay of 1 second, the delay tap is reading from 1 second into the past. Normally (no pitch shifting) you are moving the delay tap ahead in time at a rate of 1 second per second, so it always stays 1 second in the past. But if you pitch shift you are moving the delay tap ahead faster. Say it was at a rate of 2 seconds per second. Then, in half of a second the delay tap would catch up to the present time (zero delay). Any longer and the delay tap would be into the future (into the future...future...future...). I haven't yet implemented the read into the future circuitry yet, so what happens is that the delay line wraps around to its beginning, which is 20 seconds into the past.

Normally, this doesn't happen, when the delay times are relatively long and the pitch shift amounts are small. That is because we continually restart the tap readout back at the nominal delay time, with crossfading of each grain so that you don't hear any glitches. It is only when the grain size (length of time before the grain tap time resets) is long and the delay time is short. Then you can get the 20 second in the past wraparound. Sometimes this is annoying, sometimes it can be used as a feature for interesting results.
Carrousel
jjclark wrote:
I haven't yet implemented the read into the future circuitry yet......


applause
depaffect
jjclark wrote:
depaffect wrote:
I recently got a Rainmaker! Love it, but there's something confusing happening.

This is purely about the delay section btw, not the comb. Comb is off.

If the delay time is very low (eg 0.0ms - so no delay), a tap that is pitch-shifted will play again ~20 seconds later.

This is with feedback at 0, nothing patched into it except the audio signal.

It doesn't happen if the tap isn't pitch shifted.

Any ideas?

edit - actually i'm getting it in some other patches unaltered. 053 resobeat is an example - i hear a "tap" about 20 seconds after the fact!


This is a feature, not a bug! lol

What is happening is that you are trying to peer into the future...
Pitch shifting is done by speeding up the playback from the delay line. If you start out, say at a delay of 1 second, the delay tap is reading from 1 second into the past. Normally (no pitch shifting) you are moving the delay tap ahead in time at a rate of 1 second per second, so it always stays 1 second in the past. But if you pitch shift you are moving the delay tap ahead faster. Say it was at a rate of 2 seconds per second. Then, in half of a second the delay tap would catch up to the present time (zero delay). Any longer and the delay tap would be into the future (into the future...future...future...). I haven't yet implemented the read into the future circuitry yet, so what happens is that the delay line wraps around to its beginning, which is 20 seconds into the past.

Normally, this doesn't happen, when the delay times are relatively long and the pitch shift amounts are small. That is because we continually restart the tap readout back at the nominal delay time, with crossfading of each grain so that you don't hear any glitches. It is only when the grain size (length of time before the grain tap time resets) is long and the delay time is short. Then you can get the 20 second in the past wraparound. Sometimes this is annoying, sometimes it can be used as a feature for interesting results.


Oh! How interesting! Thank you for that reply. I would *never* have worked that out.

I was using it as a kind of multitap pitchshifter without delay (to make chords etc), and having the melody come back 20 seconds later was not at all what I wanted!

So I think it would be better if there was no wrap-around at all, but perhaps there are reasons why it's better that there is.

Thank you for this brain workout!
jjclark
The only way to avoid the wraparound would be to truncate the grain so that it doesn't go into the future. This would cause a glitch.

The right way to avoid this problem is to set the nominal delay to anything more than the grain size. Depending on the amount of pitch shift you can get away with a smaller nominal delay. In your case, just experiment with different delay times until the wraparound disappears.
scottmfr
Setting TAP# to COMB SIZE is a good way to get super short delay times. Then even if the Comb section is not active, you can use the Comb Size knob and Comb CLK DIV to set or sweep your delay times.

If you set the Grid to 16/Beat They'll be even shorter, or for chords if you create a stack of 1 of 16 they'll all hit at the same time. Groove types take on a more textural effect with super short delay times.
Thorsten
I got my Rainmaker as well, the module is excellent for the hot Summer of Eurorack Love.


When you come from VSTs you get that edge more with Rainmaker, and still can combine plugins in your DAW with ES-8 to use a hybrid setup.
laneo
dhoinjo wrote:
Is it normal that there's a lot of noise on the output when I turn the wet level 100% up? Or am I overlooking something? If the wet/dry level is at 50%, there is no notable hiss. But when I turn it all the way up there is really a lot of noise.
Is my input level too low maybe?


I´m experiencing the same thing. The more wet, the more noise I hear (even with all taps muted). I´f I enable/unmute any tap, I get more noise. More taps = more noise.

Also, even at 100% dry there is a small noise that changes when the screen shows different things (so it´s a noise related to the screen).

I´ve already tried switching it to another cases with a different PSU. Also tried removing every other module from the same case.

Any ideas?
InsectInPixel
Has the Rainmaker been discontinued? It's been a long time since anyone has restocked.
starthief
InsectInPixel wrote:
Has the Rainmaker been discontinued? It's been a long time since anyone has restocked.


I bought mine new in late April from Big City Music, and it looks like they still have them in stock.
MUFF WIGGLER Forum Index -> Eurorack Modules Goto page Previous  1, 2, 3 ... , 57, 58, 59  Next [all]
Page 58 of 59
Powered by phpBB © phpBB Group