terminal tedium (raspberry zero, pi2, pi3 codec / pd thing)

[seismic]

ttuitest i think requires the orac image (orac.pbm) to be in the current directory.

Thanks, that would be too easy. I‘ll check when back from shopping

[seismic]

ok - the test is running. but i think it's not working 100%.. when i look at the file the there should be the image displayed, some text, some random parameters..

i only get the start and finished message on one display... but at least the i2c interface seems to be working wupwup
also things are upside down, because i had no space to install the display the other way around... i tried to change the rotation setting in the Adafruit_GFX.cpp file. but orientation stayed the same..

[thetechnobear]

hmm... well better than nothing .. and explains why Orac is running but your getting blank displays!

are you using SH1106 ? if you were using something different then its possible/likely only some (simple) functions would work, but many others would not - code changes are needed to switch model, and also need to check if the functions used by orac are supported on a different model.

however, Im a bit surprised, you didn't get output on both screen, since its the same code...
and Id assume the I2C address is correct, otherwise the ttuitest app would complain it cannot open the 2nd display.

note: be aware, Im half remember making some code changes to ArduiPi_OLED... I think this was to make it work for dual displays (*)
Id have to go back to see what these were, and if it'd need further changes for other oled models.

(*) these are obviously in the ttui version you built from.

[thetechnobear]

also things are upside down, because i had no space to install the display the other way around... i tried to change the rotation setting in the Adafruit_GFX.cpp file. but orientation stayed the same..

just checked.... there is no support for display rotation in ArduiPi_OLED lib
the code that is there is commented out, and looks incomplete to me (that uses rotation var)
(just to be clear invert, is used for changing black to white etc)

its looks like the SSH1306 hardware supports this so should not be that difficult... or it could likely be done in the GFX lib quite easily.
but that would all need testing.

one its works, then ttuilite could then be extended to support this.

ps.
Ive been reluctant to make ttuilite configurable, since its a library... so should be an api change, so that then implies that other code changes are required further up the code stack to read this configuration from somewhere (most likely a file) - so thats was all a bit of a pain, for something that was unlikely to be used

[seismic]

however, Im a bit surprised, you didn't get output on both screen, since its the same code...
and Id assume the I2C address is correct, otherwise the ttuitest app would complain it cannot open the 2nd display.

i'll alter the ttuitest to send the last text to the second display. like that i may get proof that the 2nd display is working

[seismic]

its looks like the SSH1306 hardware supports this so should not be that difficult... or it could likely be done in the GFX lib quite easily.
but that would all need testing.

the 1306 and 1106 are not too different, sh1106 has an internal RAM"area" of 132x64. so most of the time changing from one controller to another requires a offset of 2 pixels to draw things at the same position.

rotation is a feature that usually gets implemented with a swith in the "drawpixel" function. (or doesn't, depends on where the library comes from..)

maybe i should start learing to work with git, once i see trought this..


question: why are there the aruino library and the one from adafruit?

[pld]

rotation is a feature that usually gets implemented with a swith in the "drawpixel" function. (or doesn't, depends on where the library comes from..)

There's also some bytes in the controller init sequence that determine the RAM to screen mapping. One changes the scan direction, the other the mapping so you can flip the screen without changing the drawing code. Similarly you can bake in the 2px offset.

[seismic]

There's also some bytes in the controller init sequence that determine the RAM to screen mapping. One changes the scan direction, the other the mapping so you can flip the screen without changing the drawing code. Similarly you can bake in the 2px offset.

a cool - that would be one(or two) more byte in the init sequence and then problem solved. thx pld

[thetechnobear]

ttuitest already writes to both displays.

( I double checked it was working on my tt befoe posting)

[gbiz]

There's also some bytes in the controller init sequence that determine the RAM to screen mapping. One changes the scan direction, the other the mapping so you can flip the screen without changing the drawing code. Similarly you can bake in the 2px offset.

a cool - that would be one(or two) more byte in the init sequence and then problem solved. thx pld

If you've not found it yet, bit 0 of the the segment remap parameter (0xA0) can be used to vertically flip the screen on the ssd1306. 0xA0 maps segment 0 to column 0, 0xA1 maps column 127 to segment 0. I think you currently have the latter configured.

[seismic]

i added
sendCommand(SSD1306_Set_Com_Output_Scan_Direction_Normal); /*Com scan direction*/
//sendCommand(SSD1306_Set_Com_Output_Scan_Direction_Remap); /*Com scan direction*/
sendCommand(0xa0);

to the ArduiPi_OLED.cpp file, in the section of the choosen OLED_SH1106_I2C_128x64 (line 550) display (it's not a SH1106 in my case.. but the change works)

THANKS!!

still no pixels from the top oled.. i think i'll solder a new one in...

[seismic]

I like!!

[jmsiener]

Did you build it from the fates image? Is this still on your zero based board? I feel like ORAC has to be installed on a modified Norns image to get all the stuff preconfigured so ORAC can run on top.

Meanwhile I got my TT plus OLEDs working with ORAC but when I powered in the other day I got no response... more to debug.

[thetechnobear]

I feel like ORAC has to be installed on a modified Norns image to get all the stuff preconfigured so ORAC can run on top.

thats not true

Orac/Mec etc, have zero connection to Norns... and run perfectly happily on rPI/Organelle etc that are usually based on Raspbian.

of course, whatever distro is being used, you'll have to configure for the soundcard, and might have to configure other things related to permissioning etc.

[seismic]

Did you build it from the fates image? Is this still on your zero based board? I feel like ORAC has to be installed on a modified Norns image to get all the stuff preconfigured so ORAC can run on top.

Meanwhile I got my TT plus OLEDs working with ORAC but when I powered in the other day I got no response... more to debug.

I tried both i stuggle with both.
But on the bigger computemodule with the CM3+ it ran with both. The norns image just comes with a lot of sound related gimmicks already. Like the pretty maiden.

Good luck with bringing it back!!

[fragletrollet]

...and here I just peeked inside to see if there was something I could use my Asus TinkerBoard for that can help my modular in a any way, and here I am 37 pages later, still pretty confused as to the final goal of the project in terms of functionality.

From a standpoint of a novice when it comes to programming and using microcontrollers (or single-board computers like the rPi/tinkerboard), I wonder if the challenge of building something involving alot of stuff I've never done before is reason enough to embark on this mission (altough it's no bad reason to try!), especially when it's still a little unclair what algorithms I will be able to use.

My "programming" experience is basically down to having flashed/compiled code onto a bunch of modules using teensys, and making a rotary encoder with an Arduino R3 and some neopixels... I haven't even tried out the Linux version for the TinkerBoard, as I installed the Android OS straight away in attempts of making some sort of media-server/music library thing, but that's not really working out as it feels impractical and just another step added to what my computer does. I do however have some good friends who are very experienced with Linux and can probably guide me through these aspects I'm unexperienced with regarding the digital side of the setup process.

I'm briefly known with Orac; a friend has an Organelle M that I've installed Orac onto, but haven't been able to delve into as I was too busy having fun with all the (really good) patches available. Are the different "patches" on the Organelle made with PD, and thus will work on the Terminal Tedium? There are some great algorithms in the Organelle, and I'd love to try to make an Eurorack module that can use some of those. It's also the question of the specific patch/algorithm being suited to the I/O of the TT.


...TLDR: what "patches", programs or algorithms or whatever they'd be called can be used with the Terminal Tedium?

Oh, and can I use my TinkerBoard with the TinkerOS Debian with the TT?

Following the progress with interest...

[haK]

Hi Everybody!! Its my first post YEAH!!

I am a happy TT (including the little traverse bay) owner and recently installed the amazing ORAC.

Thank you very much for sharing this with the community technobear!

I have one question though: Is it possible to use the cv inputs 3 and 6 and somehow pipe them straight into a patch?

I have successfully converted some of my patches into ORAC modules however pretty much all of my patches use the 6 cv inputs/knobs and it would be great to have them all at once available/cv-able without having to change pages.

I tried to incorporate the terminal_tedium_adc external into a patch but that didn't work.

I am aware that some of the ORAC routing and oled display wouldn't work as it should anymore, nevertheless I could take advantage of the filesystem and load my old patches without having to reboot and changing SDs.

cheers

[thetechnobear]

I have one question though: Is it possible to use the cv inputs 3 and 6 and somehow pipe them straight into a patch?

I have successfully converted some of my patches into ORAC modules however pretty much all of my patches use the 6 cv inputs/knobs and it would be great to have them all at once available/cv-able without having to change pages.

I tried to incorporate the terminal_tedium_adc external into a patch but that didn't work.

I am aware that some of the ORAC routing and oled display wouldn't work as it should anymore, nevertheless I could take advantage of the filesystem and load my old patches without having to reboot and changing SDs.

cheers

as you say, there is not really a way to do this within orac since there basically the UI doesn't have space to show 6 parameters.

but if you have pd patches that work standalone .. then you could just use sidekick to launch these.

also sidekick supports and OSC interface, so you can interface with it directly, to talk to the displays and cv etc.
you can find info on this in my TTuiLite repo

https://github.com/TheTechnobear/TTuiLite

you can see my supercollider demos for details of the osc messages that are sent/received by ttui

generally that are the same as norns, except they use 'ttui' as a prefix, rather than 'nui'
https://github.com/TheTechnobear/NuiLit ... C-Messages

[haK]

Thanks Technobear for your reply.

I guess I am going to use sidekick to launch my standalone patches and switch back and forth between them and orac.

Its mainly the CV inputs I am after in order to have TT as much integrated in my Eurorack system as possible.
TTuiLite looks interesting.

Incidentaly. The ORAC CV tools module "cvin mod" isn't that supposed to take any of the audio and CV inputs as a mudulation source?
I can only get the audio-inputs to work. When I choose any of the other inputs I don't get signal. Is this normal behaviour, bug or am I missing something?

I am also gonna checkout your OSC interface. This might actually be very interesting for my bela pepper given the lack of a display.
Thanks for the links and thanks for your great work.

[thetechnobear]

iirc
the pots & cv are connected in hardware on the TT (like bela pepper)
the four pots/cv are therefore used to control the parameters.
(as controlling parameter and menu with just the single encoder would have been 'more than tedious' )

this leaves two pots/cv plus digital inputs...

now here Id need to go check... I though, Id assigned one of these to gate/pitch... but I might have left them free,
since as you say there are a couple of CV module,
one of which can be used to create note/gate from cv/digital inputs, the other as you say is for cv modulation.

however, I half remember someone say they had an issue with the cv/gate, but can't remember what it was...
Im pretty sure I tested this, but perhaps I need to got test it again. ( * )

note: people generally have a bit of difficulty getting their head around the modulation system ( ** ) , it works but can be a bit confusing.
the thing to note is cv mod works kind of the same way as midi learn.
so you need to add the module, make sure its pointing to the right cv input, then you need to use mod learn to assign it to something.
again Im pretty sure I had this working fine... but Id need to double check this ( *)


----------------

( * ) obviously I test all features before I release anything, but its always possible that when I do an update... I overlook that a change might have some unintended impact...
in this case, im wondering the last update i did with sidekick, might not have been reflected in the cv modules... but it was a while ago, so Id have to check.



( ** ) generally for Orac, Ive got 'plans' to re-write/replace the current modulation system with a mod-matrix that is easier to understand/use and also more feature rich, but its a pretty big undertaking, so Ive not got around to starting . Whilst this is not specific to TT, I do think for Orac in modular environments (like TT) this would have significant benefits.

[seismic]

I checked the displays with a very simple program. So i could write to each one. and both worked, apart from the upside down thing which i had to fill into the init routine as well.
After i did that i fired up the ttuitest again and its now displaying on both oleds.
Little strange behaviour. Something like a initialisation problem.. But at least no hardware issue.

[thetechnobear]

interesting... I guess if we compare whats in your 'simple' little program to the code in ttuitest we can see what the difference is.
as you say, must be some initialisation thats expected...but not occurring... interesting that the issue is only on second display thought !?

something to do with I2C initialisation? (given ttui is just using as 2 separate i2c addresses, and sending exactly the same to both displays)

[seismic]

When things are wrapped and wrapped its often confusing me a little

If something goes wrong with the initialisation in ttuidevice.cpp i should see the error message on std out. But that seems to go trough seamless.
I try to replace the init procedure, in my tiny display test program the init is shrunk down to just send out an array of needed hex values, zero logic or switches for choosing different inits for different controllers like the adafruit or arduino ones have.

But i have the module mounted in my case now so it can travel with me when i go to work. That will maybe increase hands on time a little.

[mutronic]

Looking for the gerbers for the tt on the GitHub and the link is broken. Does anyone have the files or at least willing to take a screenshot of the board?

[seismic]

hmm - so, i found finally a little time to further work on the zerOrac board/software.

i replaced/recompiled "most" of the externals in /usr/local/orac/externals
now i'm only missing:

lib_abllink.~.so -> just need to search for the source and should be like all the others to compile..
libmec-soundplane.so -> donno if i need it at all?
libmec-eigenharp.so -> donno if i need it at all?

the rest is now all arm_v6 when i check with "readelf -A"

i get still the same behaviour when i try to start the orac service with systemctl. -> very slow and unresponive system that tends to completely hang.. :( sniff.