#60

Ordered the header as well as the FTDI cable from Digikey. Hopefully I will be up and running by next weekend :slight_smile:.

Just now remembered: where is the reset switch on the board and what header to use for that one? I figured I will also solder in the reset option to avoid turning off and on the whole rack every time during dev :slight_smile:

1 Like
#61

updated multipass:

  • fix for teletype front panel button press not working properly
  • fix for front panel button hold not working reliably
  • fix for grid sometimes not initializing properly
9 Likes
#62

@scanner_darkly, @tehn, do we know what the monome modules are capable of as far as CV shapes/rates/slewing/pwm, etc… ? wondering about sine waves, audio rate oscillation, wavetable capability, memory size… is more technical info available outside of the source code? Starting to mess with my earthsea and wondering how far I could theoretically push it and where to start looking, any info would be helpful.

#63

for memory usage see this excellent breakdown from @sam: https://samdoshi.com/post/2016/10/avr32-ram-and-rom-usage/

for audio rate generation you are limited by the timer resolution which is 1ms, so the highest frequency you could achieve is 500Hz. from what i can tell it’s set here: https://github.com/monome/libavr32/blob/master/src/init_common.c#L52 and could be possibly changed to something smaller - i’m not sure how safe it is though!. i really ought to give it a try though, i’m curious.

also since monome modules only generate positive CV you will have to shift output down for audio stuff.

you will also likely run into timing issues since all events are processed by the same queue. so if you, say, use i2c (which has higher priority than timer interrupts) you might get audio glitches whenever there is an i2c communication.

with this in mind it might still be interesting to try and experiment! and CV slewing and envelopes should be possible. teletype supports slewing CVs and uses 6ms rate to update them, so a simpler app that has less things to process should definitely be fine.

1 Like
#64

Thanks so much for the additional info, definitely going to spend some time seeing how far I can push these excellent devices.

1 Like
#65

Apologies if this was covered somewhere else: has anybody taken a crack at multipass kria? Would love to run it on my old Meadowphysics and free up ansible for arc stuff!

2 Likes
#66

not as far as i know! if somebody wants to take a dig, i’ll be happy to help.

#67

As part of custom firmware for meadowphysics which was focused on clocking I went down the path of tapping into one of the additional unused hardware timers on the avr32. One of the outcomes of that was a “phasor” like abstraction which I meant to merge into the mainline libavr32 but never did.

Looking at that code I was able to toggle gate outputs up to 4kHz and beyond.

…if there is interest I can dust this off and open a PR.

3 Likes
#68

very cool - yeah i think it would be a cool thing to experiment with!

#69

With Multipass, I’m starting to wonder if I could integrate the Teletype in my project «Hans» (OSC and Midi to I2c with a Raspberry Pi). That would be great. With this framework, the Teletype can become a follower, right ? (As long as give I assign it its own address)

It’s just an idea for now but it might be possible to use the USB port of the Teletype and its Trigger inputs and probably its display too. The module would serve as an IO in some way.

It’s very abstract in my mind at the moment because I only thought of that today while planning my Eurorack case. The fact is I don’t want to leave the Teletype or Crow out of the case. The Raspberry Pi used for Hans is supposed to be a « leader » but it can support a multi-leader setup + on the PCB I designed it has two different I2c busses, so there might be a way to make them work together without redundancies and/or « Leader » conflicts :thinking:

« Hans » (Is a Raspberry Pi) has two or more I2c busses, it receives OSC over WiFi and midi Over Bluetooth and « regular » midi via USB. Teletype has 8 tr inputs and 4 cv/gate output pairs , a display, a button, a cv input and a potentiometer. Both can communicate over I2c. There might be something interesting to do with the help of Multipass :slight_smile:

#70

yeah, it would be trivial to create a custom teletype firmware using multipass that would allow you to communicate with teletype hardware via your own custom i2c messages.

you would still have the issue with multi leader setup even with 2 separate i2c buses since teletype can only be connected to 1 bus. so your choices are:

  • run teletype as a leader and have it send i2c messages when a trigger is received and poll from it regularly to see if hans needs to update anything on teletype (screen/outputs).
  • run teletype as a follower so that you can control screen/outputs from hans and then poll regularly for trigger input states to detect if a trigger was received

it’s also possible to create something similar to what crow does (if i understand correctly) - run teletype as a follower but switch it temporarily to leader when a trigger is received so it can send something. not sure if this is a feasible with the i2c implementation teletype uses.

1 Like
#71

Thanks for your reply :wink:

Ah, yes that’s correct. I’m always forgetting that point…

I really want to try out Multipass so I’m gonna try to set TT to follower and write a few strings on its OLED display. But for long term usage, it’s probably not very useful to use Teletype as a simple console output for OSC messages but at some point it could become useful to have the possibility to log a few messages though. I’m gonna try that.

Yes I can test that too. If the I2c bus can handle that, I want to see how the Rpi reacts to this and if there’s no issue between the two. I’m adding this possibility to the list too.

Today, I thought of another possibility: perhaps the easiest setup, something that would not waste all the potential of Teletype (both hardware and software) would be to keep the actual Teletype firmware, and to connect it to the second bus of the RPI. I could use Hans as a bridge between bus 1 and bus 2, this would prevent any multi-master issue. Not sure about the performances of such a setup but it’s worth trying.

I could also try the new generic i2c ops and have Teletype triggering scripts hosted on the RPI. Hans has no address but I can probably catch these i2c generic op “on the fly” on the RPI.

2 Likes
#72

yeah definitely worth trying! let me know if you run into any issues or have any questions on how to set it up (i need to find the time to add more multipass documentation).

2 Likes
#73

super stoked to introduce github actions support for multipass. you can now build firmware directly on github. it’s free and it’s fast enough that it can be a feasible option if you have trouble setting up the toolchain (which can definitely be a complicated process) or if you need to build it while you’re away from your main dev computer.

the instructions on how to add it to your multipass based projects are in the updated readme: https://github.com/scanner-darkly/multipass#github-actions

you can see what it looks like here: https://github.com/scanner-darkly/orcas-heart/actions

i’ve created 2 main workflows:

build firmare

this can be triggered manually or you could change it to get triggered whenever there is a new commit or a pull request. you can select which branch you want to build too. the process typically takes 30-60 sec. if there are no errors, it will upload hex files as artifacts. you can build for multiple modules too.

update release

this workflow simplifies creating releases, especially when you target multiple modules. it gets triggered automatically when you create a new release. both hex and zip versions will be uploaded as assets to your release: https://github.com/scanner-darkly/orcas-heart/releases/tag/0.0.1

the implementations are not perfect (i don’t know bash so this was the result of many trials and errors) but i’m hoping they’ll prove useful, and more importantly - i hope this will encourage more people to try making their own apps. more updates are planned for multipass soon, and definitely more docs!

7 Likes
#74

This is amazing!! I’m excited to read the docs you’re working on and figuring out how to get started with multipass :slight_smile: already have a few ideas for my Ansible

1 Like
#75

Is there a reference for all the built in functions in multipass?

#76

that’s one of the things i need to document. for now you can see available functions here, most should be self explanatory: https://github.com/scanner-darkly/multipass/blob/main/interface.h

1 Like
#77

ok… this might be a dumb question, but what do i need to do to have the build include a few more files. trying to add euclidean.c/h and the accompanying data.c/h from teletype so I can call the euclidean() function in my control.c, but adding #include euclidean.h doesn’t seem to get the files compiled and then if i try calling the function, i get an error.

#78

you also need to include it in config.mk file similar to how control.c is included (do it for all the modules you want to build for):

1 Like
#79

so for set_gate and set_cv on Ansible, are the gate outputs 0-3 and the cv outputs 4-7 (for the output argument in those functions)?