#101

Was just working my way through the implementation to support negative voltages for my output expander and found a little inconsistency in the way voltages are handled in the Teletype code. From the web page:

These are typically used with CV output, since CV has a fine granularity (14 bit), full range which is 0-16383.

So V 10 (ten volts) is 16383. V 1 is 1638. N 1 is 137, for a semitone. This way we can use readable (small) numbers and then translate them to CV easily.

But - when I look at ā€œV 10ā€ Iā€™m seeing 16384. A quick peek at the table backing the conversion and you can see the lookup for V 10:

const int table_v[11] = { 0, 1638, 3277, 4915, 6554, 8192, 9830, 11469, 13107, 14746, 16384 };

I bounded it for the operator for the output module, but we might want to take a quick peek at the tables to ensure that the values are proper. Rounded, 16383 spread across the (11) values would be:

const int table_v[11] = { 0, 1638, 3277, 4915, 6553, 8192, 9830, 11468, 13106, 14745, 16383 };

This change also corrects the range for the VV operator as well (as it is based off the V table).

b

1 Like
#102

@scanner_darkly thank you so much for doing this!!
was just going to report a ā€œbugā€ when pressing ctrl :smile:
forgot about that too!

hex file seems to be half the size of before? can this be true? is that @samā€™s magic or will I be hitting a wall because of wrong compilationā€¦ so far everything seems to be working.

#103

not sure about the size - looking at the official releases v1.1 is ~597k, v1.2 is ~227k and the latest code built is ~242k, but both 1.1 and 1.2 point to the same checkin in git, so hard to say what was changed. i do seem to remember one of the releases included the default scenes with it, maybe thatā€™s why?

#104

ah yes was comparing with 1.1, maybe the asf diet? or the scenesā€¦

(nevertheless, big cheers to @sam too for helping out so much here and laying the foundation for future developments!)

1 Like
#105

Apologies for posting to this thread, after some internal debate it seemed like the best place.

Iā€™m working on expanding the base teletype code to support the input and output expanders for the Teletype and Iā€™ve ran into an interesting behavior that, while I await my replacement FTDI cable, I was wondering if anyone had any ideas as to what could be going on. It centers around inconsistent behavior with the metronome script vs. the trigger scripts.

Output is working great for me with the straight i2c transmissions (via i2c_master_tx); Iā€™ve been able to blast messages of varying length and everything stays solid with no perceptible timing impact. Whoot!

Input is also working pretty well. Iā€™m able to use a slightly modified version of the i2c_master_rx command to send out a message and retrieve a value. (The modification was to pass the data array into the function so that the value could be extracted.) The remote i2c device gets the command and then returns the value. It is perfect in that regard. Iā€™ve executed these pull commands countless of times from the realtime command line and as scripts running off of triggers. In fact, in a trigger, I can pound it ridiculously fast for as long as I want with any function ordering.

There is one circumstance where I can get the Teletype to lock up 100% of the time. If I add the read command to the metronome script and it is not preceded by and i2c send command, the device will lock. If there is a send command prior, I can run the metronome script for hours or as fast as I want (M 1) without any issue. It is shockingly responsive in that regard. but, if I donā€™t issue a send command prior to the read command, the thing locks instantly.

This works without fail in a metronome script:

TO.TR.PULSE 1
CV 1 TI.PARAM 1

The first knob of the input expander drives the Teleypeā€™s CV output. Again, I can run that as fast as I want (M 1) without problem. I can even read it four times in a row (there is no caching) and it blazes:

TO.TR.PULSE 1
L 1 4 : CV I TI.PARAM 1

Omit the TO.TR.PULSE 1 and the Teletype freezes - even though it will work from a trigger script.

CV 1 TI.PARAM 1

Switch to the Teletypes param and it works without error.

CV 1 PARAM

Any thoughts offhand about the metronome processing and what could be at work here? Iā€™m scratching my head a bit as the same script executed off of a trigger works. Strange.

ā€“

You can reference my fork here if you are curious beyond the above high-level question:

https://github.com/bpcmusic/teletype/tree/to_operator

b

#106

Hi all, Iā€™m kinda of back now. Iā€™ll try and catchup with whatā€™s been discussed in this thread and (eventuallyā€¦) get back to code hacking.

Did you get this sorted out? There is definitely a way to do what youā€™re asking. I can point you in the right direction if youā€™re still interested?

#107

no, didnā€™t get a chance to look into it as itā€™s simple enough to just run clang-format manually. but yeah, should probably fix. doing a quick google search looks like ppl recommend using uname or $(OS)?

#108

This is how the asf Makefile does it:

(this is also the bit that I will need to tweak to stop the rmdir errors on OSX)