#11

Not usually a fan of alt firmwares, but Orca would be a great project and I’d love to see it. It will also be interesting to see how Orca on Norns + Crow plays out.

3 Likes
#12

one request, if i may - for the potential teletype ORCΛ port could it have its own name, or some variation? there is already orca the alt firmware for white whale (and potentially other monome modules down the road, including teletype), it’s easy to distinguish between that and ORCΛ the livecoding tool since they run on different platforms, but it’ll be really confusing to have 2 different alt firmwares with the same name.

6 Likes
#13

VCRO? :upside_down_face: (and 20 chars)

1 Like
#14

There’s an implementation of a shadow buffered display driver in telescope. It’s not well-documented, but it comports to the specification set out in the display’s documentation, which is required reading if you want to play with the graphics acceleration engine.

Many of the implemented API calls related to drawing modes have been written and tested to some extent, but do not feature in the implementation of telescope. I had fun playing around with the scrolling modes and the box drawing and it all worked.

The diff-based update engine in use in telescope is well-appropriate to a scope, with few pixels changing each update. Depending on your needs, you may wish to use other re-map modes for better performance in complex scenes.

There are some builds of it starting about here:

As you can see in that thread, the diff engine in the final build was 4x faster than the full-column write in the initial builds, but only for the scope. It will be slower for a full-screen redraw, which is capped at 141 Hz, IIRC.

@sam, @scanner_darkly :wave:

6 Likes
#15

Thanks for all the valuable input, hints and code examples! Looks like there is still a lot to learn and discover before I can actually get started with something as complex as an Orca port. But I’m already digging into the code and documentation and I’ll keep you posted as soon as there’s some progress!

Sure, I’d be absolutely fine with that. There should be enough other marine mammals out there that have not lended their name to a Monome firmware yet :grinning:

Just one more (maybe a a bit naive) question: Is there any possibility to do serious damage to the TT module by uploading an altered firmware? I’ve heard several stories about people accidentaly “bricking” devices, so it would be good to know what the worst case scenario could be. So far my experience with embedded development is limited to some experiments with relatively cheap MCUs and development boards, and breaking a valuable module would be considerable worse than a fried Arduino…

#16

I really don’t think so. Nothing you can’t fix by just flashing back to the release firmware. I’ve accidentally flashed Teletype firmware onto Ansible and vice-versa a number of times, and have run bad code that behaved weird or soft-locked a lot of times, always fine after a reset/reflash. Generally I think scary things you can do are pretty well protected on modern microcontrollers precisely because stuff like accidentally overrunning a buffer is super common. Also, most hardware accesses you would want to do are abstracted away inside libavr32, so you generally don’t need to directly do any register twiddling anyway.

3 Likes
#17

Thanks, that’s good to know!

Latest addition to my alternative firmware wishlist: A Super Mario port where the TT is outputting gates/CV for the background music and triggers for sound effects. Not going to build that one anytime soon though… :sweat_smile:

2 Likes
#18

I made a table tennis simulator within teletype. Can’t find the video of it though.

It used the turtle operator (@) to bounce the cursor around the tracker screen. It could have been extended to use the 4 triggers for P1(up, down) P2(up, down) to make an actual game out of it.

I once considered adding graphics operators to the teletype codebase to draw on a new screen using the graphics acceleration of the display.

What I’m saying is that you don’t have to modify the teletype codebase that far to make games.

Also, here are my demo videos of various stages of the oscilloscope development:

14 Likes
#19

Now that I’m thinking about it, I guess there’s actually quite a bit a of low- and mid-level commonalities between TT and for example Orca, like text parsing and rendering, grid-like structures and CV processing. The turtle operator also definitely has some similarities with the way things move in Orca.

This text based sequencer I’m currently prototyping is actually even closer to the way TT works and would probably just require some changes to the data structures that hold the current state and the way the scripts get parsed/processed. It’s in some whays a bit similar to spacetime and Dunes, which I both just discovered today (and which once again made me think about getting a Norns sometime).

2 Likes
#20

Just wanted to post and say I would support the development of a full on tracker interface. That was my main draw to the teletype initially. It would be much easier to resist the NerdSeq draw that way!

2 Likes
#21

Just wanted to send some good vibes your way @lsky. Both orca and some sort of purpose built tracker sequencer sound really (as does your oscilloscope @sliderule). Good luck with your embedded firmware development journey, and I’m excited to try out whatever you eventually come up with.

If you need anything on the docs side of things, let me know. I’m open to help add a section for alternate firmwares or something like that.

3 Likes
#22

A tracker style sequencer would probably require even less fundamental changes to the TT firmware, since it already has some of that functionality.

I’m not very experienced with trackers, but I’ve tried Renoise a couple times and I really like how easily it can be customized/extended via the integrated Lua scripting API.

For the TT, an additional tracker view which can be used to sequence/trigger scripts could be an interesting way to get the best of both worlds…

Thanks a lot for the encouragement! There’s still a lot to learn, but as soon as I come up with something, I’ll make sure to share it here!

By the way, I’ve discovered this community just recently, but I’m already amazed by the positive, open-minded and supportive atmosphere around here. It’s very motivating and inspiring!

1 Like
#23

A tracker (which goes beyond TT patterns) with integrated scripting would be the dream for me.

I liked the NerdSeq but eventually I got tired of typing in all the values - even with the Patch and Table functionality.

#24

So you mean it would be more comfortable to enter the patterns with a full keyboard than with the NerdSeq’s rather limited user interface?

Renoise has this concept of phrases, which are basically sub-patterns nested within a pattern. So a single note can trigger a whole sub-pattern (kind of like a very fancy arpeggiator). Triggering specific TT scripts for single tracker-notes could be an interesting variation on that idea…

#25

If you have a grid, the grid control mode’s pattern screen editing features are great. I’ve used it before to change cursor positions and values during a live performance.

#26

It would, but I was imagining an extension of the current TT functionality where we can use Scripts to populate the Patterns, set loop points, move the play head.

NerdSeq has a similar approach with Tables and Patches which can be called from a single pattern entry.

The more I think about it, the more I feel I really just need longer TT Patterns and more of them. TT is closer to my ideal Sequencer than it seemed NerdSeq was ever going to be. :thinking:

#27

This got me thinking: I haven’t often felt like I needed more or longer patterns, but I have found myself wishing a pattern could contain more than one value per step – e.g. one value for note number plus an auxiliary value for volume, filter cutoff, time, or # of repeats, etc. Sometimes I’ve used the most significant digits in a pattern for one purpose (CV 1 N / P.HERE 100) and the others for something else (say CV 2 VV % P.HERE 100) but the tracker UI doesn’t make it easy to edit individual digits of a step value independently. I wonder if alternative methods of displaying & editing the same underlying pattern data would be worth exploring, or if that would complicate things unnecessarily.

4 Likes
Teletype workflow, basics, and questions
#28

Multiple values per steps are also something that could be done by having the pattern trigger whole scripts instead of single notes. However, this approach would still be limited by the maximum number of scripts.

I haven’t done any research about the firmware’s memory footprint yet, but it would be interesting to know, if there’s still some headroom for more/longer patterns/scripts/lines per script. The current limitations might have been deliberately chosen based on design decisions and the hardware specs (display size, number of jacks etc.), so maybe there’s still space left…

1 Like
#29

After giving it more thought over the last couple of days, More Patterns would be preferable to Longer Patterns. Being able to use Patterns P0 to P15 would be fantastic!

2 Likes
#30

Interesting idea! I’ve used a 4 digit binary number in one pattern to control 4 triggers (on a TXo) - but you’ve made me think about embedding more info into a single step.