#16

yes-- the mute would apply to all rows. otherwise the design flow would get messed up.

now though-- what does “mute” mean? does it mean that it simply doesn’t send a trigger output to the jack? (my assumption was this.) the other way of thinking of this is that a muted row doesn’t get counted down, which is a totally different (and very interestingly disruptive) behavior-- as suggested by the “stop the whole sequence”

#17

In my initial suggestion it’s the former, I still want the overall pattern of counts to be processed as normal, just no triggers coming from the muted row. The latter is also interesting, but a different feature.

#18

Do you think that the logic of it would be “broken” if the mute feature was implemented as per @kisielk’s original suggestion (sequence continues with all the links and behaviors, but the final trigger is disabled) EXCEPT for the top row, which just stops the whole thing?..

The top row is already somewhat different from the rest, so a slightly different behavior might be justified, and not confusing.

BUT
(as an alternative possibility)

If we were to stick with the logic of “mute disables the trigger, while the mechanism continues” then muting the top row could function as a form of “meta mute”: disabling triggers on ALL rows, while keeping the whole mechanism alive…
Which sounds like a pretty “clean” solution to me :smile:

What do you think?

#19

It would still be nice to be able to mute just the top row. I think there would need to be a separate combination to stop everything.

#20

Are we saying that a muted row will not trigger the other rows that are dependent on it? just that it doesn’t send an external trigger?

if its the fomer, I am not sure why its different from stopping the row completely, but if we can stop an individual trigger but still affect the other rows that are dependent on it, I see that being more musically useful.

also muting the top row would just stop the whole thing? or am I getting it wrong?

#21

honestly both forms of mute are interesting to me-- the “disable” feature (stop processing the row completely) is more musically interesting to me, whereas the “mute” (just mute the hardware output) is more performatively useful.

it feels like it’d be confusing to have both, but i’ll think on it. any suggestions are appreciated.

#22

I agree they’re both useful. I guess you could call the features “freeze” and “mute”. Would it work to just use the two rightmost keys in a row for this while holding the leftmost?

#23

I like the distinction between mute and freeze.

#24

excellent. yes let’s do the right two keys.

1 Like
#25

So

leftmost key, + rightmost key MUTES
leftmost key + two rightmost keys FREEZES

?

#26

i was thinking FREEZE is the key just to the left of mute. that way you don’t have to hold so many keys?

#27

Makes sense.

I was caught up in thinking about how the left column is always involved in any modifications…

#28

FREEZE and MUTE getting hacked into the firmware right now…

#29

SUPER!

I think these are all really meaningful additions. Very much looking forward to this.

Was thinking though, (and also based on your comments that the Teletype integration will require firmware updates to the trilogy) that considering an update procedure that does not erase the saved user settings might be worth pondering.

One of the (many) points of appeal of the monome modules, I think, is the extensive program saving and recall abilities. Sometimes, these saved configurations reflect signifficant time/effort investment on the user part.

I am learning (in general) not to build too strong attachments to any thing, but am thinking this might be an issue for others? Or maybe I am overthinking this?

#30

module updates are generally rare.

it would represent a substantial time investment to make user data portable between versions-- i simply can’t rationalize spending the time required.

given the relative simplicity of module data, i’ve taken the stance (for my own creative process) that any module setup stored in flash shouldn’t be regarded as too precious-- like a modular patch with knob settings and patch points is similarly hard to recall. the fact that the modules remember their state (if you save it) is surely helpful-- and if something becomes too important to lose, best not upgrade.

the docs outline a process for saving/downloading your flash images, also. this is simply a matter of cross-version saving. sorry!

#31

that said! new version!!!

freezes and mutes are a great idea. thanks for the suggestions everyone. much deeper module, very suddenly!

#32

hi ! will this be available for the max/msp version ?

#33

I personally subscribe to the “not too precious” concept. Was just thinking out loud about it.

Having the modules remember saved state on startup: that is huge for me, and thank goodness for that!

Now: to install the new update!!

#34

having recently worked on updates to the Intellijel Metropolis firmware which changed the schema of the saved data, I agree that having it be portable between versions is way more trouble than it’s worth. We’d have very little space left for meaningful things if we had to add that :slight_smile: Of course the MP has a much beefier chip, but I assume like most ARM micros it just stores data in flash and not a real EEPROM so I guess everything is wiped when you flash it?

But anyway, thanks for implementing one of my suggestions, I can’t wait to try it out!

#35

i’ll do a refresh mid july. if someone wants to get there before i do, the code migration is very easy.

1 Like