Yes - I’m suggesting giving him the power to drive decisions by editing to top post. My point was, the editor of the content has power. I think we agree, but I might not have been clear.
Maybe? But like you say above - without interest from someone writing the code, it doesn’t happen.
Does it? Is that because TT expects to be a USB host, so can’t act as a drive when you connect it to a computer, so it would have to be mediated by a USB hub? Just making sure I understand.
Thanks for summarizing that.
I suppose the only thing that’s different about msgpack is that you will never create scene_serialisation_v2_t, but you will instead create scene_deserialize_v2().
As such, I don’t see any advantages to msgpack. I’m liking the Base64-encoded blob.
The Teletype hardware can be both host and device. This is definitely possible, as it’s in device mode when you flash it from your computer. Whether it’s possible outside of firmware flashing would need to be confirmed, but it is supposed to be able to do it according to the spec sheets. In effect the hardware is USB OTG.
If I had the time I would extended the serialosc protocol to connect to the Teletype in device mode. Then you could multiplex grid, arc, keyboard and MIDI into the Teletype, and send OSC out of the Teletype (e.g. to Ableton…). Anyway, this time it’s really the last time I will discuss this on this thread!
@sliderule updated the top post to reflect the state of the conversation. That’s very helpful, thanks @sliderule!
re: binary format.
it’s not just a question of adding new structures. if you want to modify an existing one you are now forced to add new members at the end of it. same story if you change any array sizes (scene text as we discussed). unless your binary format accounts for data size changes (each section has an offset to the beginning of next section, for instance).
listing pros/cons sounds like a good idea. also i’d like to add another +1 to @sam’s comment on giving @sliderule opinion bigger weight since he’s going to be the one working on it.
re: tt as usb drive - wasn’t there some ability to transfer presets via usb cable similarly to flashing firmware? i can’t find it in the docs… but i guess you’d still want to be able to switch it from device to host without a reboot (this would actually be useful for firmware dev as well).
You just need to cut and paste the struct, make your changes, and change the name of it to the new version, scene_serialisation_v2_t would become scene_serialisation_v3_t. You’d then need to provide some functions to forward convert the older struct to the newer one (or provide parallel versions of the code to convert the struct to scene_flash_t).
The binary file contains a header with a magic number and version so that we know what it is.
Also by keeping a separation between the serialisation structs and the internal use structs, we have a bit of freedom with regards to internal layout of data structures.
It’s not perfect by any means, but there is a clearly defined logic to it. IMO the problems you’d have with different versions of text file format will be harder to deal with.
I’ve stated earlier in this thread that I’d prefer a text file format. The question is whether the extra work required to make a robust text parser is worth the investment.
Or alternatively, what would we prefer? A text format that would be harder to provide backwards compatibility with, or a binary format.
I do think it’s worth exploring alternate ideas for how the binary serialisation would work. I didn’t put a lot of effort into what I wrote earlier, so there might be much better ways of doing it.
see, that workflow to me is an argument against binary format, not in favour of it.
text serialization IS this separation.
this is where we disagree… imo text format makes backward compatibility much easier.
i mentioned orca code too many times already but in my humble opinion the code is very robust and not hard to read/write/maintain. but that is debatable, of course… as a side note, once you have string parsing/conversion functions implemented for most data types you could probably use ragel to generate serialization/deserialization for you by writing a mapper file and running ragel on that.
curious if you’re thinking text mode preset export for orca? part of my thinking right now with tt has an eye towards more universal approaches to preset saving, ie ansible.
yeah, sorry, should’ve been more specific, storing/reading presets to/from usb.
my push for a more generalized approach is so that it could be easily added to trilogy/ansible/future firmwares. it was definitely one of the most time consuming parts of writing the firmware!
the other idea i mentioned of sharing some parts of presets between different firmwares - not sure how really usable/practical it is (my thinking was also that different firmwares have different ways to build scales which could be used as something beneficial - if you use ww but prefer how scales are built on kria you could use presets to transfer, or we could publish popular scales and they could be used for different firmwares by copy/pasting). another use case for this would be transferring presets between trilogy and ansible versions (although this could also be done with a smart binary format).
I think @scanner_darkly is right in that it would be good for monome modules to have a unified serialization scheme.
At this point I note that I don’t need to touch anything about the serialization to continue with the USB work, and the topic is important enough to merit its own thread for long-term planning. I’m head-down working on documentation for 2.1, so perhaps @scanner_darkly or @sam would like to summarize and organize our collective thoughts to this point in a new thread?
No need to defer to my opinion on this one. I can write the code later once the community agrees on a direction.
Edit: Or we can use anyone’s code!
I have no idea if this is possible from an implementation perspective - but could TT act as a USB drive? Both the OP-1 and Octatrack become USB drives when connected to a computer.
After experimenting a bit with USB, I can say with certainty… “probably”.
600 lines of code down, maybe 200 to go?
usb_disk_mode.o: In function `screen_refresh_usbdisk': usb_disk_mode.c:499: undefined reference to `ud_draw_save_confirm_dialog' usb_disk_mode.c:499: undefined reference to `ud_draw_bank_selector' usb_disk_mode.c:499: undefined reference to `ud_draw_load_bank_confirm_dialog' usb_disk_mode.c:499: undefined reference to `ud_draw_bank_scene_selector' usb_disk_mode.c:499: undefined reference to `ud_draw_flash_scene_selector' usb_disk_mode.c:499: undefined reference to `ud_draw_load_confirm_dialog' usb_disk_mode.c:499: undefined reference to `ud_draw_ok_popup' usb_disk_mode.c:499: undefined reference to `ud_draw_error_popup' usb_disk_mode.o: In function `ud_save_scene': usb_disk_mode.c:499: undefined reference to `ud_serialize_scene' usb_disk_mode.o: In function `process_usbdisk_button_press': usb_disk_mode.c:499: undefined reference to `ud_get_bank_count' usb_disk_mode.c:499: undefined reference to `ud_new_bank' usb_disk_mode.c:499: undefined reference to `ud_save_bank' usb_disk_mode.c:499: undefined reference to `ud_get_flash_scene_count' usb_disk_mode.c:499: undefined reference to `ud_select_bank' usb_disk_mode.c:499: undefined reference to `ud_get_bank_scene_count' usb_disk_mode.c:499: undefined reference to `ud_new_bank_scene' usb_disk_mode.c:499: undefined reference to `ud_get_bank_count' usb_disk_mode.c:499: undefined reference to `ud_live_bank_is_empty' usb_disk_mode.c:499: undefined reference to `ud_load_bank' usb_disk_mode.c:499: undefined reference to `ud_get_bank_scene_count' usb_disk_mode.c:499: undefined reference to `ud_get_flash_scene_count' usb_disk_mode.c:499: undefined reference to `ud_new_flash_scene' usb_disk_mode.c:499: undefined reference to `ud_load_scene'
$ wc -l usb_disk_mode.c 1078 usb_disk_mode.c
I had to rewrite the existing deserialization code to decouple it from an actual scene state. If anyone’s interested in peeking at the text parser, it starts around here.
Now for the least fun part:
usb_disk_mode.o: In function `screen_refresh_usbdisk': usb_disk_mode.c:120: undefined reference to `ud_draw_save_confirm_dialog' usb_disk_mode.c:120: undefined reference to `ud_draw_bank_selector' usb_disk_mode.c:120: undefined reference to `ud_draw_load_bank_confirm_dialog' usb_disk_mode.c:120: undefined reference to `ud_draw_bank_scene_selector' usb_disk_mode.c:120: undefined reference to `ud_draw_flash_scene_selector' usb_disk_mode.c:120: undefined reference to `ud_draw_load_confirm_dialog' usb_disk_mode.c:120: undefined reference to `ud_draw_ok_popup' usb_disk_mode.c:120: undefined reference to `ud_draw_error_popup'
Paging @laborcamp!
Could I employ you to do some illustration for me? (Your username makes this question slightly uncomfortable 
)
Generic Menu Screen
Confirm Dialog
Bank / Scene Selector screens to show up to:
If you could design and draw up some graphical solutions for those UI elements, I can finish out this feature.
I’m cool integrating whatever bitmaps you want to use, and can also do line art.
Ok. I will tackle this tomorrow!
Before I get going on this a couple of questions.
It seems that you, @tehn and @sam offered examples of the menu/function structure. Is there a consensus on the final function set? I am asking because seeing what the whole thing does will help me generate a few visual/interface solutions.
Only the button, and the PARAM knob are used to navigate this, correct?
This will be entirely new interface (meaning no other existing interface elements are present), correct?
Font grid for the entire screen is 32x8 characters, correct?
We have agreed on the menus, I think. There are really only 3 menus, the rest are selectors.
Top:
Save:
Load:
The rest of your assumptions are correct!
Almost… it’s 8 lines, but the font is proportional, so it’s approx 32 characters.
Right.
Just wanted to get that 32x8 ‘ballpark’ reference confirmed.
Thank you.
How is this to start the conversation:
If people think this is a good approach, then the Configuration Menu
could be laid out in a similar fashion.
I think visually it fits in the Teletype sensibility.
The big question is whether you agree on my navigation suggestions:
—PARAM to scroll the current menu with the selected item being highlighted. Then button press to select that item and move on to the next menu, until the final YES/NO commit is reached. Selecting YES commits to the function, and moves the highlight back to the top menu. Selecting NO moves you back to the previous column/menu.
—Scrolling using PARAM knob CW moves the highlight down the menu, and loops back to the first item of the menu, when the highlight reaches beyond the bottom menu item.
—Scrolling using PARAM knob CCW moves the highlight up within the menu, and moves back to the previous menu, when the highlight reaches beyond the top menu item.
What do you think?
