#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)?

#80

no, it’s 0-3 for both.

#81

cool! follow-up question…

why does

add_timed_event( GATE_OFF_TIMER + i, FIXED_GATE_LENGTH, 0 );

throw an error but

u8 timer_index = GATE_OFF_TIMER + i;
u8 gate_length = FIXED_GATE_LENGTH;
add_timed_event( timer_index, gate_length, 0 );

does not?

GATE_OFF_TIMER and FIXED_GATE_LENGTH are both #defines.

#82

what’s the error? and how are they defined?

#83

oops my bad… i had semicolons after their #defines :man_facepalming: