#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
#36

you’ve been coding for danjel? good to hear-- he’s a great guy.

the avr32 probably isn’t more advanced than most arm chips, and yes, everything stored in flash. which is great, in my opinion!

#37

This is all interesting!
And, somewhat related: I love my uScale, and my biggest (maybe the only) gripe with it is that there is no way to save a startup setting. Every power on is like starting from scratch, requiring several interactions to just bring it back up to where it was left.
So, I was excited to see that there are some imminent firmware updates for a few Intellijel modules, including uScale. Answering my question about this specific issue Danjel suggested that that would be one of the implemented changes. I am so excited for that.
In this case, it’s not so much about “precious” or not: just streamlining usability.

#38

Awesome!

Although I just spent yesterday working on adding a different functionality to MP that would effectively add the mute feature, I just can’t debug or do anything with the code I wrote (having trouble getting avr-gcc installed/working). I was just getting ready to post something about all this on the firmware mod page, seeing if anyone wanted to take a look at it or help me get up and running, but here is even more MP specific - I’m really curious if this feature seems useful to anyone else:

The functionality I was trying to add is to allow MP to use the grid to manage the mapping of row events to CV outputs (as opposed to currently row 1 event maps only to output 1, etc), including mapping multiple row events to one output or one row event to multiple outputs (or none, thus the mute). This would let you create polyrhythms on a single output or easily double parts on the fly without having to touch any cables (or use a second MP row - which could then instead run and trigger rules but have no assigned CV trigger out). The desire to add this functionality was born out of this post. A combo key press brings up an 8x8 matrix on the right half of the grid. Toggle whether triggers output to CV outs 1-8 across each row for that row’s event. Default mapping is current behavior (row 1 only to output 1, etc). None of the output mapping affects any other behavior, including applying rules or row linkages.

Not having personal experience with MP, I’m still not sure if this functionality would be that useful (it seems to me like it would be), but decided it would be worth the personal exercise to try to execute regardless. I’m also not a professional programmer, I’ve done some MC programing but is my first AVR coding attempt. I’m sure there’s something I’m missing / not doing right, although I feel pretty good about the logic at least and the code feels right (I’ve only added/changed a few lines). I haven’t used Github, but it seems that’d be a more elegant way to share the code I wrote than uploading it here so maybe I’ll sign up? If I do upload here I think I’d rather use the Firmware Modding thread. I’d really rather just get X-AVR working to let me work in Xcode and debug and build it myself (I mean who wants to debug someone else’s code, right?). Anyone have experience there and be willing to help be out?

Anyway, hooray for MP support for TT! I predict a couple more updates in the near future…you guys sure are busy these days!

Let me know if I should keep working on this output matrix mod for MP (or post code if anyone’s interested)!

Eurorack firmware modding
#39

I finally got to installing the new firmware version (not sure why it took me so long, it’s stupidly easy to do…) and the new mute and freeze features are pretty great. Exactly what I needed.

I think the only thing remaining on my wishlist for MP right now is a way to do logic between two channels for an output. Basically Right now I use the output of two channels going in to another logic module to get more complex rhythms. I’ve tried to achieve something similar to OR using the minimum and last pressed rule, but it doesn’t quite work as I’d like. I guess it’s easily achievable with Teletype taking triggers but that seems like a bazooka solution to something which needs a hammer. I can’t really think of what could be a good interface for doing something like that directly in MP though, and perhaps it has enough features as it is…

Also a gentle reminder to add the new features to the docs so other people know they’re there :smile:

#40

yes! doc update is on our list.

do you have any ideas for a way to implement an or?