#188

Great - Thanks! And let me reassure you that I have absolutely no interest to push the things in the extreme just for the sake of and I do not see much musical use in letting everything flicker at audiorate either…

#189

The 2.0 release notes mentions “visual glitches” as a known issue :

“The cause of these is well understood, and they are essentially harmless. Changing modes with the key will force the screen to redraw. A fix should hopefully be coming in version 2.1.”

Is it these glitches that are displayed in the video above, and is a fix still scheduled for 2.1 - @sam @sliderule ?

#190

I wasn’t aware of this issue. If someone opens an issue on GitHub, I’ll try to track it down for 2.1

2 Likes
#191

Brian opened this issue:

I know exactly why it happens… but it was too late in the 2.0 process to try fixing it. The short version is:

  • CV outs are updated using a timer…
  • The CV DAC is updated over SPI
  • The timer can interrupt the main event loop
  • The screen is updated in the main event loop
  • The screen is updated over SPI
  • Ergo, CV updates can interrupt screen updates, causing screen corruption (but it doesn’t cause any issues with CV generation).

At the time, I decided that we’d finally gotten the Teletype firmware to the point where is was very stable, and we’d finally understood why it was crashing when it did. I didn’t want to risk that stability by having to tackle the issue of locking access to the SPI bus.1

@scanner_darkly was looking at it though. He has a fix for the issue on the master branch of libavr32, but that requires changes to be made to all the modules to be made compatible. So far only Earthsea has been updated. I think there is a branch on his repo with the changes made to Teletype too. Things are hazy though (baby brain…), there are some threads on here where we discuss it.

I think either those changes need to be made to all the other modules, or we need to revert them, or do some git shenanigans with branches. At the moment it’s hard for anyway to make any changes to libavr32…

1 and I was a bit fearful of doing it too, you mentioned to me how long you’d been coding in C, well… this is the first C I’ve every done! (Though I have dabbled with C++ and Obj-C in the past.)

3 Likes
#192

to clarify, there were 3 separate issues:

  • i2c reliability
  • crashes in extreme conditions (super fast metro script, audio rate triggers)
  • screen glitches / keyboard responsiveness.

only the first one requires also updating trilogy / ansible. for the last 2 only teletype needs to be updated. there is no requirement to update everything to the latest libavr32 - they should all be compatible. you would only want to update everything to the latest libavr32 if you experience i2c issues.

as a side note, with my changes i got it to the point where i could not get it to crash at all, this is running for over 40 hours with 10ms (could’ve been 2ms, don’t remember now) metro script, audio rate triggers and lots of reading and writing over i2c (ansible and 5 telex modules) in the metro script.

2 Likes
#193

In the 2.1 beta thread, we decided that LAST should take a script number as a parameter so that scripts can check on other scripts, perhaps as a watchdog-type event.

Because of this change, it was decided to add a THIS operator to facilitate checking the current script number.

It was noted:

I found myself commonly using SCRIPT with mods, making for long commands. I think SCRIPT should have a shortened alias because it’s a common place to use THIS, which pushes the text length up quite a bit for a common use case (SCRIPT THIS is recursion).

Maybe a special operator for SCRIPT THIS?

Here’s an idea I had while I was falling asleep, and was wondered if anyone would make use of it:

Turtle
Based on the concept from LOGO, a turtle is a 2D index that crawls around the patterns as laid out in the tracker. I’m going to use improvised syntax here, but the idea is simple:

@         <--- that's a turtle, it tells you what it's standing on
@.LEFT 1  <--- move turtle left one column
@.DOWN 2  <--- move turtle down two rows
@.WRAP    <--- set wrap mode, walk around the edges
@.BUMP    <--- set bump mode, stopping at the walls
@.BOUNCE  <--- set bounce mode, reversing direction and continuing
@.DIR 90  <--- set the direction to 90 degrees
@.FWD 3   <--- move 3 units forward in the current direction
@.TURN 45 <--- turn 45 degrees clockwise
@.X 1     <--- jump to column 1
@.Y -10   <--- jump to the tenth to last row
@.POS 1 1 <--- jump to position 1,1 and set as home
@.HOME    <--- jump home
@.SHOW    <--- show the turtle on the tracker screen

Even if nobody likes it, I’m doing this for my private branch to make arpeggiators. :slight_smile:

12 Likes
#194

Turtle sounds fantastic (love the use of @). It will be very easy to create Rene-style voltage maps.

4 Likes
#195

Hahah, my first programming experience was Logo lessons when I was a kid…
I like this very much.

1 Like
#196

Whoa, Turtle just gave me a crazy idea. Probably a bit silly and labor-intensive.

I’m imagining a way to attach a Grid to the Turtle, so that you can display the active step on the Grid and use the Grid to potentially set the Turtle’s next location.

6 Likes
#197

Buttons to control the turtle, I love it!

3 Likes
#199

Grid Interface idea:
The top four rows are the four tracker columns rotated on their side. The brightness of each button corresponds with the value of that location (might be too complicated with the huge range of useful values and purposes)

In the bottom four rows:

  • A small D-pad for manual piloting of the turtle
  • Four buttons to select the active page (since there are 16 visible steps and 64 possible)
  • Elements for controlling the active range of the turtle (if you just want a 4x4 for instance)
  • Maybe something to change between WRAP, BUMP and BOUNCE
1 Like
#200

I love this idea. Logo is so special, and I can see wanting to do this with pattern data all the time.

#202

I love this idea! I worked on something similliar within the current operator set but did not get to nice solution by now.

I wonder if @.DIR X would have ha a default setting/direction so you can start with a predefined direction or set it before starting. Something like it will always start going downwards unless you start or initialize it with @.DIR X to have it move in another direction?

I think a grid display solution for this is a nice idea, also with additional controls on the free space. Though they should work in realtime then while teletype is event based by now.

Rotating the four tracker columns to the side would mean that the first tracker column will be the lowest on the grid and the last tracker column will be the top row on the grid - so the numbers would be reversed. I would find this more counterintuitive than having them mirroring the tracker view with a bit of scrolling if you really want the turtle to live in something bigger than a 4 x 8 grid.

How about staying with the screen and using four keys to change the direction - like Alt + ?

#203

First, i must say i’m in awe regarding all the hard work, dedication and imagination this module has gathered. It’s really a great thing to see this ecosystem grow.

Owning a TT myself and having no coding background, i’ve only made baby steps with it, with much pleasure i must say in each case! So a lot of the technical discussions here goes beyond my head. If the point of view of a “basic” user is useful here, i would like to point out a few things (and sorry if my post is not that much relevant!) :slight_smile:

  • The tutorials and studies are an incredible learning tool, and it goes beyond learning the code : it drives you to think differently about performing, about composition etc.

  • For the same reason, i must say that as a basic user i’m overwhelmed by what is going on in V2 and didn’t dare too update yet as i am not feeling confident enough with the new things… As the docs are in constant evolution and the forum topics are filled with implementation discussions, i think new tutorials are greatly awaited to convert what we can understand of new ops, into what they can mean in musical contexts… Can’t wait too see and study new ones. At the moment i think (maybe i’m wrong) updating would mean too much investment and a learning curve too steep for the time my job and family leaves me for it.

  • Lastly, i remember (but maybe i’m mistaken), that tehn talks in an early topic on V2 about Midi ops. I must say that this is high on a personal features request list for the TT ; i use some time Ansible as a Midi converter and it would just be a dream to have MIDI ARP OP in TT, or MIDI CLOCK OP for example, with rate, direction, division, etc. under TT control. The TT shouldn’t only be open “from the inside”, by extending its own power and capabilities, i think it should also open itself to other machines, following the path of TT remote for the trilogy, the Telex expansion etc.

Any way, that was my 2 cents!

7 Likes
#204

The turtle idea is great - I remember using logo back in the day. I was also recently thinking of ways to use the pattern page to emulate the Kilpatrick Pattern Generator and there it is.

Also, I think now is the time to raise this … PONG!

:stuck_out_tongue_winking_eye:

#205

turtle would be absolutely terrific!

#206

i do like turtle.

it’s important to acknowledge that the feature increase will be overwhelming to new users, but i really think this can be mitigated by well-sorted documentation. i’d sort turtle (as well as ER, JI, and some others) into a “specialized” category (perhaps there’s a better word, but “advanced” is not correct).

this way the introduction can unfold methodically as it does now, introducing new capabilities-- and then there can be almost an addendum series of specialized op’s/etc.

also to clarify turtle:

@ is the same as P.N @.X @.Y correct?

to SET a value (x) at turtle position: P.N @.X @.Y X

so could we use @ X as “set at position” like above?

is @.HOME 0,0?

2 Likes
#207

Certainly.

By default? Yes. I used 1 above for the example because I forgot that patterns and pattern data were 0-indexed :wink:

Yup. North (up) is 0. @.DIR default would be 180.

I think everyone knows how a circle works, but we could add some aliases for the cardinal directions if anyone thinks that it’s needed. NORTH, SOUTH, EAST, WEST maybe? For that matter we could have LEFT, RIGHT, and AROUND for relative positioning. I personally am fine without these.

I used @. with the period for everything, but I’d be more than glad to drop it. Save a character, and because @ is so notable, there won’t be any namespace conflicts. @HOME, @DIR, @SHOW etc.

1 Like
#208

this turtle business is awesome! kudos for everything, @sliderule!

3 Likes
#209

Thanks!

Aside: We need more people to put the 2.1 through the ringer. I’m happy to have the beta period last a long time, but only if it’s getting tested! I’d hate to release it after a few weeks only to find bugs then because it hadn’t been well-tested enough.

FYI: beta2 has no known functional bugs or crashing, but your complex, but everyday script might find one! I’m particularly looking for testers with other monome gear connected over i2c to ensure that complex setups are unaffected.

1 Like