#122

2.1 release date is October 12.

I can absolutely handle those PR requirements.

1 Like
#123

Is that the date for you opening the PR up? Or the date you want to release the firmware. You should factor some time in for review of the PR.

Life makes it a bit tricky for me to target specific dates at the moment. Might be best for you to get on with 2.1 and I will merge the cheatsheet in afterwards.

#124

I never even thought of this, despite its obviousness. I had planned to whip together a build once I get docs and formatting done, call it the release, tag the code and open the PR, but now I can see that this might be overstepping.

I’m not sure if @tehn, @cmcavoy, or yourself would have enough time in the next while to review some ~2700 lines of changes in any meaningful sense, so I have to presume that my PR will be accepted carte blanche for all intents and purposes.

The proof is in the pudding, IMO: the firmware builds and functions without known bugs. As a developer I know how much this statement reeks of hubris, but it’s a perspective that might be the most appropriate for this codebase, its developers, and the time they have to dedicate to the task.

Given some of the bugs I’ve found (did you know that there’s a blindingly-obvious buffer overflow in the USB code?), I can’t see stringency being applied to my PR at a granularity that exceeds that which has been applied already. (Scent: arrogant.)

Additionally, I’ve openly vetted all relevant design decisions with @tehn to prevent him from having to suss them out from the code and analyze them.

But, you know, I never asked @tehn about the release at all. I just picked the day that I would be done with 2.1 and called it. I guess that was pretty rude in retrospect. I struggle to strike a balance between incessant and presumptive and this time I missed. Sorry!

Anyhow, this is off-topic for this thread. I’ll engage the rest of this discussion in PM.

#125

“Review” is perhaps a strong word. It’s more just giving people a few days to cast their eyes over the code, and see if anything particularly obvious stands out.

As you suggest, it’s unlikely that anyone will have enough time to really look at it. But I will try and make the time to at least pull it locally and build my own copy (and run the tests, compile the docs, etc, etc).

I have no idea what @tehn and the others have planned. It’s possible that they’ll be happy to just hit the merge button as soon as the PR opens, but I also want to make sure that you’re not surprised if it takes a few days for that to happen too.

1 Like
#126

i’ll be sure to make time to review the code-- though it won’t be exhaustive.

and then i’m happy to merge pretty quickly-- i’ll test the newest candidate. the older candidates were working well. but let’s make sure the PR fits the guidelines re: formatting etc-- you seem to be on that.

i’m happy to get 2.1 out for people to use-- it also opens the path for @scanner_darkly to release the grid ops.

6 Likes
#127

Unfortunately, I don’t have the skills to do reviews for the project, just suggest ways to organize things.

1 Like
#128

i should be able to take a quick look.

3 Likes
#129

late to the party since I’m moving right now… but great work on the cheatsheet @sam!

1 Like
#130

so is 2.1 available as yet?

#131

2.1.0 will be released tomorrow.

If you’d like to try it sooner than that, you can check out RC2 which is 100% code-compatible with 2.1.0-release.

2 Likes
#132

I’ve pushed my cheatsheet branch:

https://github.com/samdoshi/teletype/tree/cheatsheet

I’ll rebase and PR once 2.1 is merged.

5 Likes
#133

Also been working with @sam on getting the version from the git tags rather than hard coding (ended up doing this for both the prompt on the teletype itself and the html/pdf docs). Definitely some cleaning up still needed, but plan is to get this in shortly after the cheatsheet branch gets merged in. Commit here

This will be my first C contribution (albeit a very tiny one), but I’m pretty excited about that! Shoutout to Sam for a lot of guidance on how I should approach this.

3 Likes
#134

I have rebased my branch on to master@monome/teletype and opened up a PR:

Here is the PDF (now with Turtle OPs included!): cheatsheet.pdf (65.9 KB)

Unless I hear otherwise I will hit the merge button myself in approx. 24 hours.

4 Likes
#135

@sam looks like it’s been merged, nice! I’ll open up a pr against master with the version changes we’ve talked about this evening.

#136

looks like some of the docs that were removed from the teletype page did not make it into the new manual, specifically USB flash drive scene read/write that can be seen as part of Teletype 1.1 Addendum here: https://web.archive.org/web/20170609025605/http://monome.org/docs/modular/teletype/

could somebody re-add that section? or if somebody could point me to what’s the latest process for editing the docs is i can add it (is it just editing toml/md files?).

1 Like
Grid ops / integration
#137

re: usb drive saving:

missed this on the first round, was going to bring it up from a related thread.

if someone has a minute, thanks! else i’ll get it in next week.

2 Likes
#138

But sometimes new users are performing firmware upgrades fairly soon and I for one would still find some default scenes helpful.

1 Like
#139

Please add parameters, options, and recommended editors (such as Notepad++ or whatever they might be) for saving scenes as saving it as a simple .txt file out of Open Office didn’t work for me.

#140

@unity2k re editors, if you list which work (i know there was a thread here somewhere) i’ll add them to the docs.

1 Like
#141

That’s the problem, I don’t know and can’t find it though I have stumbled across it before.