#21

on the other hand, it will be forgiving when you include extra spaces or edit it on different file systems with different file endings. i see it as a benefit. but yes, as mentioned already this mostly benefits something with a far more complex data structure.

worth mentioning that orca methods are far from being optimized, but they definitely saved me a lot of time when writing USB code.

1 Like
#22

if we were redesigning it from scratch i would go with JSON, yes

anyway, sorry for getting this discussion off track, we can discuss serialization elsewhere and keep this thread for its original purpose.

1 Like
#23

It will need to be done if we’re going to have any talk of file compatibility while being able to change the file format at all.

We could infer the lack of a #VERSION string (or whatever) as a legacy file, and start adding it to new patches as the file format changes (for TL, for instance).

1 Like
#24

That was my thinking too.

2 Likes
#25

Another thought occurs to me:

Facet 10: USB mode must automatically launch when a USB stick is inserted and must automatically close when a USB stick is removed.

3 Likes
#26

Yes, and to follow up. What happens to any running scripts?

(The original USB disk code only worked at power up.)

When I hacked the USB disk code to work whenever a stick was inserted, I think I cheated a bit, and just unbound all the event handlers, did the USB stuff, and then rebound them (quick enough for the event loop not to overflow, and even if it did, it didn’t really matter).

That method won’t work if you want to have an interactive USB disk mode. You’ll need to cleanly shutdown the normal Teletype “app”, and then restart it on stick removal.

Really the USB disk mode is at a level above all the other modes (live, pattern, etc). It exists in parallel to the entire Teletype app. In some respects calling it the “USB disk app” is more appropriate. And it might even be wise to do that in code so that we don’t confuse it with the other modes.

On a tangent. Could we add the current “edit” script as a first class save and load target?

i.e. when saving all scenes, also save the scene that is being edited to say ttEDITs.txt. But even better, allow loading a scene directly to the edit scene.

Speaking of filenames… do you wish to add a facet regarding filenames? Do we want to change them at all? (And are we limited to FAT 8.3 length names?)

#27

Just a thought–

Instead of or maybe in addition to building a more complex UI for users to interact with on the teletype, why not build that utility into some sort of program to be run on the computer (probably GUI based so as to feel approachable to all types of users). I feel this “Teletype Helper” utility would have some benefits over teletype-based management (just some ideas below):

  • Auto back-up of scenes onto a secondary source (computer HD) to help mitigate overwrite issues.
  • Ability to access a community collection of scripts (via the internet)
1 Like
#28

Feel like this is something that’s important to think of going forward. I like the idea of going directly to the “management” mode when a usb drive is inserted @sliderule. But if we’re thinking in terms of the “monome ecosystem” (grid + arc + keyboard accessible with teletype at once), that may complicate things.

#29

Yeah that could be possible, and I don’t see why not.

I was thinking that we leave the filenames alone, bar dropping the “s”, and put them in folders like bank1/ bank2/ etc. If that sounds good to everyone, we’ll go that way. I think we should stay constrained to 8.3 for ease of programming.

Given that there is no automatic write in the new design, I don’t think users need overwrite protection anymore.

As to creating a workstation application for management, I think that’s quite a change in scope. Consider: which OSes do we support? What windowing toolkit works for all those OSes? Which OS’s file presentation idiom should we choose? What does this offer that a user couldn’t do with the OS’s built-in file management utilities?

2 Likes
#30

Definitely, just wanted to present it as a possibility. To be honest, I’m not sure of how “finite” the resources are on the Teletype, but I would personally like to be cautious of using a large chunk of them for the purposes of file management. It may be in the best interest to utilize those resources for more “critical” things. Totally talking out of my depth here though–this may be very little code/take up very little memory on however Teletype stores it’s firmware.

Provided there’s some open standards around accessing USB devices (not something I’ve worked with in the past, so I’d definitely want to do some research), I feel like you could make a lot of these considerations irrelevant by building something on the web.

EDIT: interesting article on Chrome support for USB devices.

#31

Not only is this not an issue, but this feature development is at @tehn’s request, and is necessary to develop some more advanced features that will change the file structure.

The last thing I want to do is build a browser-dependent interface to a local filesystem. Just my preference, though.

1 Like
#32

quick thoughts:

serialization option: http://msgpack.org

menu proposition, simplified. (< means back to previous level)

  • save
    • collection
      • save to (list collection numbers) (+ <)
    • scene
      • list scene (currently loaded) to save (1-32) (+ <)
        • save to collection (+ <)
          • save to scene (+ <)
    • <
  • load
    • collection
      • select collection (+ <)
    • scene
      • select collection (+ <)
        • list scenes 1-32 (+ <)
          • select position to load into (+ <)
    • <
  • exit

i’d like to skip script and pattern copying as a USB function, in preference of having hot keys to copy/paste each(perhaps with confirmation, which would be a new modality) with the keyboard plugged in-- provided we’d need a buffer for each.

ie, hotkey copy the pattern data, load a new scene, paste the data, confirm, done. or: copy a script, move to script 2, paste, move to script 3, paste. etc. load another scene, paste script.

1 Like
#33

one thing-- i’m not necessarily certain that we need the tt files to be human readable.

it’d be trivial to include a command-line util to dump a packed file to a text version.

i’d highly advise against doing some sort of computer-based editor/manager/anything. it shouldn’t be necessary. if someone needs to backup their collections (banks), they can just copy the files.

#34

Yeah–I think I’m missing a lot of context here, will follow this on the sidelines. Definitely appreciate the work you’ve done in designing this and on 2.1.

I do think it’d be cool to surface up some sort of utility that helps to enable sharing and community around Teletype scripts/scenes.

Feel like this is a bit of a misrepresentation of what I was suggesting but ok…

#35

Are we looking to abandon the text file format going forward, then–

Oh I guess that answers that. :slight_smile:

By “list collection numbers”, do you mean to display a list of all collections that can be scrolled through with the param knob? In essence creating a flat list that includes the back button? Sounds workable.

10-4. That simplifies things.

#36

this is important, i overlooked it a bit.

theoretically a js-based msgpack-to-markdown would be also trivial, for easy posting here. it’s just a matter of where people’s passions exist…

yeah, i think so. i guess there should be a “new collection/bank” option when saving? your suggestion not to list blank collections/scenes is really really good.

3 Likes
#37

Agreed, it’d probably be better not to couple that sort of thing with the management of the files running on the teletype. Also, if we could keep this kind of thing in lines that would be awesome from a community perspective.

Something like being able to upload a TT scene file to lines, which would auto-expand that into readable code-formatted blocks for each script, as well as put a download link to the script so that another user could download said script.

(EDIT: obviously getting far away from the goals of this thread…gonna follow along and see if I can start to come up with something)

1 Like
#38

Yeah that would be necessary. Sounds like we’ve got a decent framework to start with.

A question: how should the pattern knob behave? Like an index into the list, or like an encoder with a fixed step distance?

#39

i do think there is been too much push to make things humanly readable in software dev world in general, but i think it makes a lot of sense for teletype (and other firmwares). having to run a command line utility or some web based interface introduces a barrier and a new dependency (which can be OS version or JS version dependent itself). with the github for sharing teletype scenes i hope there will be much scene swapping / submission / discussion, having an extra step when you want to just modify a scene would cool it down a bit, i’m afraid.

also, based on my work experience developing a good binary format that would be future expandable is much more difficult compared to a text based format. and even if at some point a breaking change is introduced it’s easy to just manually edit the text, as opposed to having to write / run some kind of conversion utility.

3 Likes
#40

Thinking about serialization, I wonder what our goals are. The application scope, as far as I can see is:

  • Read and write scenes between Teletype and USB disks for the purpose of backing up and sharing them between Teletype modules and users.

Advantages to serialization libraries might include

  • Compact storage
  • Efficient and safe packing and unpacking of data
  • Portability
  • Simpler code

Disadvantages might include

  • Input / output not human readable
  • Increased firmware binary size

My question is this: given our application, do we need any of the advantages?