P.MIN is a very welcome addition. Previously I had to sacrifice an entire script to do get an argmin.
How does it handle a tie? does it return the index of the first occurrence or the last?
I went through the same.
Not sure if this belongs here or in the Teletype 2.2 thread … I’m running the latest beta:
Executing TI.PRM x when x is greater than the highest param input (in my case, greater than 12) locks up the Teletype.
Calibrating my TXi and Parameter went fine. On the TI.IN.CALIB is it a matter of preference to set our TXi to -10V thru 10V or 0V to +10V, or is it your recommendation to set it to the full range?
What is the factory default? Edit: Just read that there are no defaults set.
I’m getting “Unknown Word” with: TO.CV.CALIB 1
This generally happens when there is insufficient pull-up on your i2c bus. How many devices are you running and do you have a powered bus board?
The Teletype can generally handle approximately 3 devices before things are unstable - but this is also affected by the length of your cable runs. In my experience, reads fail more consistently first. Unknown ports/devices are a sure fire way to get an unstable bus to lock your Teletype. The solution - a powered bus board.
Full range. I did calibrate this last batch of TXi before sending them. Don’t believe the documentation. It is full of lies. Big, fat, blatant lies.
(Or I printed it before deciding to calibrate them.)
Yeah - you need the firmware that was merged into @scanner_darkly’s branch. It isn’t available yet.
I have a backpack on the Teletype that currently feeds (2) TXo, (3) TXi, and a JF. Overall system power is a lightly loaded Intellijel TPS30 MAX. I haven’t had any stability issues otherwise.
After some more investigation, the problem arises when trying to read past 32. This is fine:
L 1 32: TI.PRM I
But this hangs the Teletype:
L 1 33: TI.PRM I
The problem arises when moving code around that uses a counter as the index for parameter reads: sometimes the line that does counter reset gets deleted etc., and the counter goes over the limit and locks up the Teletype.
Ah! Now I understand. There might be a bounds error when calling beyond the 8 supported devices. I’ll look into it. Thanks for clarifying.
While I wasn’t able to replicate the hanging Teletype with my development setup, I went ahead and put bounds checks in as they were something I should have been doing anyway. I’ve submitted a pull request for @scanner_darkly. Depending on his timeframe - hopefully this chance can make it into the grid release.
Thanks again for reporting it.
new beta firmware for the Teletype supporting the new features listed above is now available here:
Bug report: v0.19 TXi issues.
I don’t know where to begin with this one except with the hardware and firmware versions:
Teletype w/backpack running grid/ops latest
(3) TXi running v0.19
(2) TXo running v0.19
(1) Late model Just Friends with I2C connection
TI.PRM x returns 0 or weird values on TXi running v0.19. TI.IN seems to be affected too. I tried a mix of firmware revisions (two TXi v0.18, one TX v0.19) and the v0.18 TXis worked fine and th v0.19 did not. Reflashing everything to v0.18 fixes the problem except that there appears to be an issue with TI.PRM.MAP …
… namely that full CW can return 0 when e.g. TI.PRM.MAP 1 0 7 is in effect. Backing off from full CW will return the expected 7. (EDIT: right after posting, it occurred to me that I ran a calibration on the params and then swapped Teensies around while troubleshooting … this could explain what I’m seeing, so hold off chasing that one!)
This took a while to isolate due to a bad Teensy in one of the TXis–not sure how that happened! I completely remove the Teensy to flash it, so it’s not a magic smoke issue. Stuff happens.
@bpcmusic is up to some shenanigans that I’d bet a dollar on will have some of us wanting more Telex units and whatever this mystery Telex unit is shaping up to be?
Looks like a Nopass filter.
MIDI? with 20 characters
That makes sense to me!
Maybe just an i2c jack for multiple case setups?
@bpcmusic From your Instagram post regarding the Teensy 3.6 I think I can see that the longer board simply hangs over and that not all the pins are connected, but this is working anyway?
If we were inclined to go forward and purchase this upgrade to our current units, would this be as good a time as any?
Do you have a concise list of improvements the Teensy 3.6 would offer over the current boards?
Edit: Okay I see faster processor, a lot more ram…
#1: Bug Report
Dang! Can you PM me what you mean by weird values? I’m not 100% sure what you are experiencing here. I’ll test myself as well.
#2: Odd TXb Thing on Instagram I Posted
Yup. It is a simple little thing that I’m toying around with. If you look at my initial thoughts for the TELEX line way up top of the forum, I’d always planned a little i2c expander module with a stereo 3.5mm i2c jack. That’s what this is.
Current prototype has a 14-point bus in the back that functions as a powered bus board if you connect europower. On front it has a 3.5mm stereo jack. This jack can be used to connect the upcoming 16n faderbank to your i2c bus or to connect a second TXb in another case - both using stereo audio cables. (In the latter circumstance, you should only connect one of them to europower.)
Totally not ready for prime time yet. Proto boards are on their way from OSH. Specs subject to change. When baked it will be 100% open source (like TXi & TXo).
#3: Teensy 3.6 on TXo (@unity2k)
Just got the Teensy 3.6 I’ve had for ages sort-of working connected to a TXo. It took a little firmware fiddling due to the slight differences in the 3.6’s behaviors.1 I’ve finally got the unit running at twice the clock speed as the original TXo!
Now - I’m going to experiment what that can give us in terms of increased quality and additional features (and identify if there are any other differences that cause problems). No timeline for this, btw. I’m just fiddling. If and when I get close to making anything of it, I’ll certainly post a notice here.2
1 Two primary issues with upgrading to the 3.6 from the 3.2 was 1) the dumb way I did the address jumpers by reading positive voltage instead of pulling the pin to ground (total Arduino 101 mistake - the STEM kids at Venice High will spit at me as I drive by on my way to work) and 2) having trouble reading i2c commands - the 3.6 was always one command behind. Fixed #1 by reading the analog voltage of the config pins as opposed to digital and fixed #2 by upgrading the Teensy i2c Wire library - the version shipped with my version of the Teensy loader apparently had a gnarly bug in it. Now - we are in business.
2 Please don’t take my Instagram account as any official announcements of anything. I like to be pretty open with what I’m fiddling with. Some stuff goes nowhere. Some stuff takes years for me to figure out. That said, I’m always happy to share what I’m up to and thinking of - anyone who has followed this thread knows I’m a windy fellah.
Thanks for sharing and hopefully you will continue the stream of conscience hitting forums to help inspire others.
I for one do not mind if I ever see any of the modules, programs, ideas or dreams of others coming to fruition, as just the thought of some of them inspire chains of potentiality to influence new ideas and my aspirations of continuing to try and innovate. For anyone to be able to lend an aha moment to someone else is already gift enough.
To think that if and when I gain some mediocre competence regarding the endeavor I currently enjoy, that I could extend that capability with minor adjustments or upgrades is simply a delightful thought. Knowing that new challenges are currently being undertaken to force my puzzle solving skills to evolve is an elixir containing elements from the fountain of youth.
Oh, one more thing: does anyone have a part number and a source for the pins used on the Teensy?