Marbles

I thought the “Bias” parameter was supposed to be able to accept 1v/o but the other night I plugged my Keystep into it and when I hit the keys absolutely nothing happened. An LFO into it worked fine though. Maybe I’m missing something?

yep

3 sec long press on T give you 3 other modes:

-independent Bernoulli
-divider
-three states

don’t know how to get the Markov model yet

case SWITCH_T_MODEL:
{
uint8_t bank = state->t_model / 3;
if (e.data >= kLongPressDuration) {
if (!bank) {
state->t_model += 3;
}
} else {
if (bank) {
state->t_model -= 3;
} else {
state->t_model = (state->t_model + 1) % 3;
}
}
SaveState();
}
break;

From memory the markov mode isnt exposed in the ui

thanks - yeah, Id figured it out :slight_smile:
I check the code and it looks like the Markov model is not accessible, perhaps it didn’t work out ?

perhaps we just need to change a line of the code?

Yes

I asked about Bias being 1V/oct a while ago. To quote @pichenettes:

:slight_smile:

Oh interesting. OK. So I’m wondering if I’ll be able to do something else I had in mind then. I’m about to buy a Digitone/Mutant Brain and I wanted to clock and send CV to the Marbles with it. My idea was to send clocks from the sequencer and different CV values per clock to the bias. I’m hoping this will be possible.

Anyone else using sequencers in interesting ways with Marbles?

1 Like

Hello,
Could someone describe the behavior of the 3 other models ?

I can imagine for Divider, but it is more difficult for the 2 others.
Also, what is the difference between complementary and independent Bernoulli ?
Thanks.

from Nino:

For those who might be interested, i just investigated the alternate modes and tried to figure out what they do. I only listened to the t outputs.

Green alternate:
Bias still sets the propability for a trigger on T1 or T3 to occur, but the decision is no longer made between those two. Instead a trigger can occur on both or on no channel according to your settings and the dice.

Yellow alternate:
Polyrhythm machine. One channel gets multiplied, the other divided. Here is what ratios i heard going from 12 o’clock to CW (no guarantee).

T1 T3
x1 x1
/1.25 x1.25
/1.3 x1.3
x1 x1.3
/2 x2
/3 x3
/4 x4
/6 x6
/8 x8

Instant afro/poly machine around 12 o’clock. Made me empathize Olivier’s “when it sounds great with just clicks…” another time.

As i did not explore the default red mode too much i wouldn’t be sure what the alternate does. At first it seems to include patterns with more triggers. It also sounds a lot afro. Yummy.

Then Pichenettes:

Congrats for figuring out green and orange. Red is a variant of the coin toss (branches, normal green) mode, with a third choice in which no trigger is generated.

https://www.muffwiggler.com/forum/viewtopic.php?p=2843408#2843408
https://www.muffwiggler.com/forum/viewtopic.php?p=2843426#2843426

3 Likes

Thank you very much, i made a reseach with “model”, “bernoulli” and “divider” keywords and didn’t found this post :wink:

is there’s a new firmware for marbles?

It doesn’t look like it. 1.1 is all I’m seeing on the site.

This topic is turning into a big mess…

I’ve created a separate topic for this issue.

1 Like

quick question regarding the gate length

Hold the button [E] and turn BIAS to adjust the gate length from 1% to 99%

when I use Marbles with the RATE at 9 o’clock or even slower, I would like the GATE to be a lot shorter than the 1% option. When pinging a filter or JustFriends in Plume mode for example.

It would be great if the GATE where TRIGGER in this case. Could it be possible to modify the code in a way that if someone go full CCW with BIAS, the GATE became TRIGGER?

Or even better, to be able to have in all the BIAS spectrum a possibility to have really short GATE to normal length GATE when using BIAS to change the length?

I found this in ui.cc

case SWITCH_T_RANGE:
      {
        if (mode_ >= UI_MODE_CALIBRATION_1 && mode_ <= UI_MODE_CALIBRATION_4) {
          NextCalibrationStep();
        } else {
          state->t_range = (state->t_range + 1) % 3;
        }
        SaveState();
      }
      break;

and this:

void Ui::UpdateHiddenParameters() {
  // Check if some pots have been moved.
  for (int i = 0; i < ADC_CHANNEL_LAST; ++i) {
    float new_value = cv_reader_->channel(i).unscaled_pot();
    float old_value = pot_value_[i];
    bool changed = fabs(new_value - old_value) >= 0.008f;
    if (changed) {
      pot_value_[i] = new_value;
      AlternateKnobMapping mapping = alternate_knob_mappings_[i];
      if (switches_.pressed(mapping.unlock_switch)) {
        if (mapping.unlock_switch == SWITCH_T_RANGE && new_value < 0.1f) {
          new_value = 0.0f;
        }
        *mapping.destination = static_cast<uint8_t>(new_value * 255.0f);
        cv_reader_->mutable_channel(i)->LockPot();

        // The next time a switch is released, we unlock the pots.
        setting_modification_flag_ = true;
      }
    }
  }
}

but I don’t think it’s relevant.

found a typo in a comment though:

/marbles/ramp/slave_ramp.h

27 // A ramp that follows a mater ramp through division/multiplication.

Hard, because the code is written in terms of % of the main period, not of absolute duration. So you can’t easily change things to emit, say, a 1ms pulse.

I’m not sure I understand what you’re looking for.

The limit is not set in the UI layers. It’s down in the code that converts ramps to gates, and the fact that the module thinks everything in terms of ramps won’t make things easy if what you want are times.

so would it be possible to set the minimum to 0.1 % or 0.01 % to broaden the spectrum?

never mind, I don’t really understand the code that much, so I don’t know where to look.

But you got my idea I guess. If triggers - respectively a fixed duration of pulse - is not possible, maybe it’s possible to get shorter ramps

I looked at the code again. I now remember that I had to reduce the range to 5% to 95% instead of 1% to 99%, because it was too easy to mistrigger some destinations due to extremely short output pulses.

Try using something like 0.005 instead of 0.05, and 0.99 instead of 0.9 in the following lines.

Maybe use pulse_width_mean_ * pulse_width_mean_ instead of pulse_width_mean_
to get a better adjustment range.