MUFF WIGGLER Forum Index
 FAQ & Terms of UseFAQ & Terms Of Use   Wiggler RadioMW Radio   Muff Wiggler TwitterTwitter   Support the site @ PatreonPatreon 
 SearchSearch   RegisterSign up   Log inLog in 
WIGGLING 'LITE' IN GUEST MODE

temps_utile / 6 x clock generator [build thread etc]
MUFF WIGGLER Forum Index -> Music Tech DIY  
Author temps_utile / 6 x clock generator [build thread etc]
mxmxmx


... teensy 3.1/3.2 6-channel trigger generator/clock distributor.

hardware specs:

- teensy 3.2 @ 120MHz, w/ 128x64 OLED
- 16.67kHz update rate, < 100us trigger-to-output latency
- 2 clock inputs (> 100k input impedance; threshold ~ 2.5V)
- 4 CV inputs (100k input impedance, -/+ 5V, assignable to (almost) any parameter)
- 6 clock outputs (5 digital, 1 DAC (12 bit): 10V (GPIO), -/+ 6V (DAC))
- two encoders w/ switch; 2 tactile buttons.
- 14HP, ~ 25 mm Depth
- stupid name courtesy of M. Louis Lapicque

firmware:

6 (independent) channels / 6 modes per channel:

- trigger sequencer/sequence editor
- clock division/multiplication
- LFSR
- random w/ threshold
- euclidian
- logic (AND, OR, XOR, NAND, NOR, XNOR)
- DAC (channel #4 only): random, binary, "Turing", logistic, sequencer/arpeggiator

hardware/software/etc:

https://github.com/mxmxmx/temps_utile-

build guide:

https://github.com/mxmxmx/temps_utile-/wiki/build-it




original post:
Quote:
i can't seem to access any of the older threads, so here's a dedicated one for this thing, too (the one on the right):



ie, the firmware/documentation/build guide is up (sorry i took a little longer than expected):

https://github.com/mxmxmx/temps_utile-/wiki/Temps-Utile

i'm out of boards, so that'll mostly interest people who already have one. (though the gerbers are on github, too). it's a fairly quick/simple thing to solder up.

[....]

i'm not quite sure why i made this; but it's ok fun, it turns out.
ac
Thank you for sharing this, I've been wanting to build something similar with the Teensy.
midirobot
hello mxmxmx

great job you do!!

as the older posts are not working i would ask you here
if you still have eurotrash player board in stock ?

thanks
mxmxmx
midirobot wrote:

as the older posts are not working i would ask you here
if you still have eurotrash player board in stock ?


yes, pm me if interested.
midirobot
hello

PM sent.
mxmxmx
fyi -- these just turned up here. i've pm'd everyone (i think) who said he/she wanted boards.

there's a few leftovers, too. good for practicing SMD, not least; no $$$ parts, mostly just a bunch of 0805s and SOIC; the annoying stuff is through-hole (electrolytics etc)

puzo
hi, are there any boards left, whats the price on them? cheers
mxmxmx
...

[edit: removed outdated information]
jazzmonster
mxmxmx
I'd like to order 1 PCB if you have any left. PM sent. Thanks!
flab
interested as well ,pmed you
spotta
Will you be putting a blank .fpd up Max?
mxmxmx
spotta wrote:
Will you be putting a blank .fpd up Max?


sure, there is one here : https://github.com/mxmxmx/temps_utile-/tree/master/hard

that's the one in first post, on the right.
spotta
My bad, it was 4xCV that I couldn't see one for.
jazzmonster
Just received the board in the post, thanks a lot! Do you happen to have a mouser cart for it? Thanks
flts
This (and Eurotrash) will be good SMD practise before trying out Braids and Clouds (yikes). The OLEDs arrived already, now just waiting for boards to arrive and some extra funds to actually order all the SMT components. I guess most of the stuff aside the DAC is available from Tayda and the likes.
midirobot
ciao

just received the board,all is allright!!thanks Max!

want to ask to the other pepole who managed to build one,
i saw for the oled on ebay
oled
but they don t deliver to Italia,can we arrange something?
thanks in advance
mxmxmx
jazzmonster wrote:
Just received the board in the post, thanks a lot! Do you happen to have a mouser cart for it? Thanks


i don't, sorry ... the BOM includes a few parts numbers here and there (encoders, switches), but there's no really odd parts involved so most of it should be readily available from other sources (e.g. tayda).

as for the mec switches, the cheapest source i know of is https://www.soselectronic.com/

that's their part # 102166 ( 5ETH935 Multimec Switch to PCB 10x10mm 3,5N (Black))

they don't have the right caps though; minimum order 50 eu, too.

midirobot wrote:
they don t deliver to Italia, can we arrange something?


huh, that's weird. i don't have any left but you'll probably be fine going with some other seller (this looks pretty much identical, for example).
midirobot
great max the one you linked deliver to Italia:)

thanks
mxmxmx
someone asked whether this thing could be used for outputting audio -- i figured that might be of more general interest. so, A: in principle: yes (there's a 4 pole filter placed after the DAC), but i actually hadn't tried with the display; it turns out they work together quite happily *:



(* i was lazy, so for trying it out, i just quickly hacked up the orgone accumulator code; so that's what that is, running at 66.666kHz)
flts
^- That's cool. I've actually wished for a really simple "allround programmable" module for all kinds of audio and trigger gen, looks like I'll have to do some experimenting once the mouser order gets here and I have the time to build the thing.
pld
In case no one else has tried it: the b&w Adafruit OLED seems to work just fine on the board, with either ssd1306 or sh1106 driver. And at 144MHz smile

I'll install the jacks and encoders when I have the panel, but I still have to adjust the panel layout and at least put some "programmer art" on it smile But I've measured pulses on the outputs with a clock input so looks good.
lamouette/rck
No clock multiplier ? only diviser ?
mush
lamouette/rck wrote:
No clock multiplier ? only diviser ?


The thing with this module is that it is very easy to code for. Making a clock multiplier isn't very complicated. As you can code it like any arduino, you can just use the "mills" counter between incoming pulses and divide the number you get...
mxmxmx
lamouette/rck wrote:
No clock multiplier ? only diviser ?


nope, though it's kind of on my list. it'll need some proper timers going on underneath, not a big deal; i just didn't get round to it. as mush said, it's fairly easy to write code for this kind of thing, add modes, etc. there could be a pattern editor type thing; DAC stuff is very rudimentary, too; someone suggested turing machine; and so on.
mxmxmx
fyi:

courtesy of pld, here's a firmware update for temps_utile; the current parameter settings are stored permanently now, so on start-up things will return to whatever you had dialed before powering down.
Sandrine
mxmxmx C'est bon que tu as utilize le nom d'origin francais, bien fait, mais une question:

Are the clocks sync'ed/syncable together and if so in what fashion?

Is the a manual?

Yay OLEDs!
mxmxmx
Sandrine wrote:
mxmxmx C'est bon que tu as utilize le nom d'origin francais, bien fait


yeah, sorry, i'm kind of bad with names... it sounded better than the english or german equivalents though; here's an explanation : https://github.com/mxmxmx/temps_utile-/wiki ... which is also where the manual is.

and here's a crap video where you can't see much (... ipad 1), so i lost interest. but you get the idea.


in this case, clock output #2 (LFSR mode) triggers one voice, #6 in LOGIC mode (channel 2 XOR channel 3) triggers another, with channel 3 in EUCLIDIAN mode. #5, also in LOGIC mode (channel 1 OR channel 3), triggers the ASR (the thing on the left). #4 doubles up as a 12 bit DAC, this goes into the ASR, too; here, the DAC simply tracks the state of the outputs (channel 1 = MSB, channel 6 = LSB). one of the ASR outputs modulates clock channel 2 (LFSR, tap position).

Quote:

Are the clocks sync'ed/syncable together and if so in what fashion?


yep, they're synced in that there's one main clock and all the outputs derive from that, much like any 'clock distributor' module only with a few more modes (division, random, lfsr, euclidian, logic). it's pretty basic: an interrupt happens, the outputs are updated, the next state is calculated; the display is updated, the thing waits for an interrupt. so it can't be clocked too fast (as in kHz), but that's not the point of it.

Quote:

Yay OLEDs!

!
flts
Finally building my Temps-Utile (yellow PCB). Question to mxmxmx in particular:

It's almost done, but I seem to be missing a 79L05 - either I don't have any around and didn't order them with rest of the parts, or I have them and they're just lost somewhere in the bins. My local stores are failing me, so it's either 1h+ trip for one component, hoping a friend has one, throwing the PCB to "will finish once I order the last part online and it arrives" bin or trying to be clever.

So. Can I kludge a full size 7905 on the backside (minding pinout and if I can fit one), or is there some kind of minimum current limit or similar that makes sure it won't work instead of 79L05? As far as I can understand they're basically the same circuit in different package, but just wanted to make sure.

Or if I can't fit one, what about substituting with a negative L-series regulator with a slightly higher voltage and pretrimming accordingly? As there's no schematic (?) I'm not 100% sure what that regulator is doing but based on quick look at the PCB it looks like it might be only used together with the trimmer for setting an offset for the CV inputs...?

Btw. The BOM in the Wiki seems to be missing a couple of extra 100K resistors (I counted more than 10, there's already 8 under the Teensy), and one 6K8 that are on the board. Also, I thought there were only 4x 330nF capacitors (one has a bigger footprint and says 0.33 instead of 330nF) and couldn't find a place for 1uF unlike in the BOM? Not sure if these are "hidden" somewhere in plain sight or just left out from the board revision. Looks like there's a newer (or older?) "blue board" BOM in the wiki as well but I have one of the yellow ones.
mxmxmx
ups, yeah, the BOM has a few errors. sorry, my bad. (and thanks for pointing it out). just use the 1uF where it says 0.33. (the "blue" one is newer, basically the same thing but not using any of the funny SMD pins on the belly of the teensy.)

about the 79L05: the input circuit is here (scroll down to "CV inputs"). so yes, it's for offsetting the CV (to 1.65V); if you have any, preferably i'd suggest using a LM4040 + resistor instead *. either sot-23 or TO-92 will work, and basically any value: 3v3, 5v, 10v, even 2v5 (you might need adjust the 49k9 resistor). ie *like so:



but if you can fit it, the 7905 should be fine. most parameters have only 32 steps or so, so noise etc isn't terribly important in any case.
flts
^- Great, thanks!

I think I _should_ have spare LM4040s of more than one value. Edit: Found a spare LM4040DIZ-5.0 in TO92! Now I'll just have to figure out which way the pins should be connected when replacing the 79L05. Clip NC leg off, anode (-) to common / GND pad, cathode (+) to output pad, and a resistor between input and output? Or anode and cathode in reverse?

How about the extra resistor - what does it do / between which pins should it go / how do I pick a sensible value for it? Not really familiar with LM4040 at all yet, I've just been using them in some DIY kits as instructed so far. Based on datasheet it looks like it sets an operating current for the shunt reg, but I'm not sure how it should be calculated in this circuit.

I'll replace the 0.33uF with 1uF in the spot with the bigger footprint.
mxmxmx
don't worry about the 1uF cap, .33uF should do.

and yep, it should be doable, but you can't solder it straight onto the TO-92 footprint. since we need a negative reference voltage, the cathode (pin 1) should go to the ground pin, pin 2 (anode) to the pad/trace connected to the trimpot ( = Vout pin); then solder the resistor across the remaining pad (Vin/middle pin) and the anode/Vout. ignore pin 3, it's NC.

as for the resistor, the formula given is R = Vs-Vr / Il-Iq. Vs = -12V; Vr depends on your reference. Il is the load current, Iq the current through the diode, which should be ~ 50 uA < Iq < 15mA. so if you have, say, a LM4040-10, a 510R resistor or so would be fine.
flts
mxmxmx wrote:
and yep, it should be doable, but you can't solder it straight onto the TO-92 footprint. since we need a negative reference voltage, the cathode (pin 1) should go to the ground pin, pin 2 (anode) to the pad/trace connected to the trimpot ( = Vout pin); then solder the resistor across the remaining pad (Vin/middle pin) and the anode/Vout. ignore pin 3, it's NC.


Thanks - makes sense, I got it the other way round when looking at the datasheet but I forgot it's a negative reference voltage.

Quote:
as for the resistor, the formula given is R = Vs-Vr / Il-Iq. Vs = -12V; Vr depends on your reference. Il is the load current, Iq the current through the diode, which should be ~ 50 uA < Iq < 15mA. so if you have, say, a LM4040-10, a 510R resistor or so would be fine.


How would I calculate / know the load current in this case? I have a LM4040-5 around. Something like 1.8K resistor for Vr = -5V?
Altitude909
Got an extra OLED for O_C so I guess this is next since a clock module is sorely needed in my setup. Anyone need boards? I'll have 2 spares..
mxmxmx
flts wrote:

How would I calculate / know the load current in this case? I have a LM4040-5 so would roughly the half (220R) do?


guestimation ... it'll not be much, ~ 1mA (there's the four 49k9 resistors in parallel + trimpot in series going into the op amps). you'll need to double or triple the resistor though ((12-5)/220 = 31mA). if you have a spare 1k2 or 1k8?
flts
^- Sorry, I was editing my previous reply as I recalculated and realized I did it wrong. So yep, have a 1.8K, just soldered it in smile
flts
Getting errors about multiple declarations while compiling. Arduino 1.6.6, Teensyduino 1.26, latest code from temps_utile- repository. Wonder what's wrong? The IDE gives error highlights in strange rows that seem to not be actually related to the issues.

/Users/vae/Documents/tmp/temps_utile/clocks.ino: In function 'void clocks_restore_channel(params*, const channel_settings*)':
/Users/vae/Documents/tmp/temps_utile/clocks.ino:130:93: error: 'void clocks_restore_channel(params*, const channel_settings*)' was declared 'extern' and later 'static' [-fpermissive]
static void clocks_restore_channel(struct params* p, const struct channel_settings* settings) {
^
/Users/vae/Documents/tmp/temps_utile/temps_utile.ino:120:6: error: previous declaration of 'void clocks_restore_channel(params*, const channel_settings*)' [-fpermissive]
volatile uint8_t _adc;
^
/Users/vae/Documents/tmp/temps_utile/clocks.ino: In function 'void clocks_store_channel(const params*, channel_settings*)':
/Users/vae/Documents/tmp/temps_utile/clocks.ino:138:91: error: 'void clocks_store_channel(const params*, channel_settings*)' was declared 'extern' and later 'static' [-fpermissive]
static void clocks_store_channel(const struct params* p, struct channel_settings* settings) {
^
/Users/vae/Documents/tmp/temps_utile/temps_utile.ino:121:6: error: previous declaration of 'void clocks_store_channel(const params*, channel_settings*)' [-fpermissive]
void adc_timerCallback() {
^
flts
FWIW works fine with Arduino 1.6.5 so probably 1.6.6 breaks something in linking or similar.
mxmxmx
flts wrote:
FWIW works fine with Arduino 1.6.5 so probably 1.6.6 breaks something in linking or similar.


ok, sorry for the hassle. their constant IDE updating makes things something of a moving target ...

can't really tell what's going on with 1.6.6. the error certainly is a bit weird ( ... /temps_utile.ino:120:6: error: previous declaration of 'void clocks_restore_channel ) . there's no mention of clocks_restore_channel etc near line 120 or 121
pld
Yeah, 1.6.6 seems to have changed a bunch of settings/warnings. I'll give it a look...
flts
I'd gladly help as well but living with configuration, linker, environment etc. issues at work 5 days a week makes me a bit hesitant to do that on free time. I tried throwing around ifdefs and other brute force stuff like that for a while before I gave up and tried an older version of Arduino, hope it's a simple fix.

Got firmware uploaded in mine (did that before cutting traces etc.) and Teensy in place, and sawed a 14HP panel - drilling and panel component fitting time tomorrow I guess!
pld
I can compile it on 1.6.6 with this fix but didn't try it with 1.6.5 or on hardware smile Arduino IDE collects/mangles the source files before they hit gcc, I guess that's why the error output doesn't always correspond well, but I've never really looked into it.
mxmxmx
compiles fine with 1.6.5, but i didn't try either -- any reason you declared them static?

btw @altitude909, if you haven't ordered yet, i still have plenty of said 'blue' pcbs (= temps_utile_rev_gerbers.zip); same thing, just touched up a few things:

flts
I guess it doesn't make much sense to declare out-of-class functions static as they aren't going to be per-object and their visibility is global anyway...? So can't see why it wouldn't work.
pld
They're static mostly out of habit I guess...

static in that case means "not global, used only in this source file", or correctly something like "only visible within this translation unit", so it's a hint to the linker as well as other programmers. "static" isn't compatible with the "extern" storage class, which their compiler process seems to be trying hmmm.....

tl;dr: pld == nerd, .ino != .c/.cpp smile
flts
pld wrote:
static in that case means "not global, used only in this source file", or correctly something like "only visible within this translation unit", so it's a hint to the linker as well as other programmers. "static" isn't compatible with the "extern" storage class, which their compiler process seems to be trying hmmm.....

tl;dr: pld == nerd, .ino != .c/.cpp smile


Yep, seems like Arduino sketches aren't considered compilation / translation units in the same way as C/C++ source files... That, or the postprocessor does weird things to the code.
sammy123
Max I'd like to grab a board.

Have you thought about a random clock mode?
mxmxmx
sammy123 wrote:
Max I'd like to grab a board.

Have you thought about a random clock mode?


sure.

... and there's two random modes already. one is plain 'random' (with threshold); the other some sort of linear feedback shift register, which can be fairly irregular, depending on length and tap positions. (the one obvious thing still missing is clock multiplication ... )
flts
Finally finished mine and as far as I can see everything works fine except

1) The encoders I used (Alps EC11 clones from eBay) work in reverse
2) The two tact buttons do nothing

Issue 1 can fix by tweaking firmware. The second issue is a tougher one.

I've used the recommended tact switches and made sure they're soldered OK, but nothing happens in UI when I press them. Any ideas where to start troubleshooting? If nothing else, I'll try to trace the PCB a bit tomorrow and see if there's something missing or wrong.

Edit: obviously I can't test all channels as the channel selection isn't working, but at least it eats external clock and spits out whatever is configured on channel 1 so I assume it's working otherwise smile
mxmxmx
re 2), so that's the two multimec switches, right? they should increment (top) or decrement (bottom) the channel that's being edited. long pressing the top one should take you to the CV menu, long pressing the lower one will just display the screen saver and frequency (if clocked externally)

the pins in question are GPIO 4 and 5, they should read 3v3 normally, and go low when pressing the buttons. there's just the two pull up resistors (the two right by the upper switch) and two caps involved, so there's all that much that could go wrong. weird though that it's both of them?
flts
mxmxmx wrote:
re 2), so that's the two multimec switches, right? they should increment (top) or decrement (bottom) the channel that's being edited. long pressing the top one should take you to the CV menu, long pressing the lower one will just display the screen saver and frequency (if clocked externally)


Yup, the Multimec ones specified in BOM (5GTH935). Measured that both make contact between upper and lower pin pairs when you press them. Tried pressing quickly, long press, etc., in both the trigger display screen and settings menu, they just do nothing at all.

Quote:
the pins in question are GPIO 4 and 5, they should read 3v3 normally, and go low when pressing the buttons. there's just the two pull up resistors (the two right by the upper switch) and two caps involved, so there's all that much that could go wrong. weird though that it's both of them?


Yeah, looks like neither of them works. Looked at underside of the board again - looks like the switch pins are all soldered OK, and the resistors + caps are in place. The caps (legend "0.1") should be 100n, right? And resistors 500R / 510R?

Otherwise I guess I'll have to start probing tomorrow.
mxmxmx
oh, wait. i think i've inserted a little bug when updating the code the other week:

can you try this? https://github.com/mxmxmx/temps_utile-/tree/master/soft/temps_utile
sammy123
It's right there in the documentation. Sorry about that.

mxmxmx wrote:
sammy123 wrote:
Max I'd like to grab a board.

Have you thought about a random clock mode?


sure.

... and there's two random modes already. one is plain 'random' (with threshold); the other some sort of linear feedback shift register, which can be fairly irregular, depending on length and tap positions. (the one obvious thing still missing is clock multiplication ... )
flts
mxmxmx wrote:
oh, wait. i think i've inserted a little bug when updating the code the other week:

can you try this? https://github.com/mxmxmx/temps_utile-/tree/master/soft/temps_utile


Pulled latest changes, updated the firmware, and now the buttons work as well! Thank you! Will have to check further and calibrate tomorrow (shouldn't stay up much later than this...).
mxmxmx
flts wrote:
mxmxmx wrote:
oh, wait. i think i've inserted a little bug when updating the code the other week:

can you try this? https://github.com/mxmxmx/temps_utile-/tree/master/soft/temps_utile


Pulled latest changes, updated the firmware, and now the buttons work as well! Thank you! Will have to check further and calibrate tomorrow (shouldn't stay up much later than this...).


ok, cool ... (me too)
flts
A 4-module patch from yesterday evening, Braids + Clouds + Turing Machine Hybrid + Temps-Utile (all self-built):

https://www.dropbox.com/s/uwa384d9nn5kpak/braids_clouds_turing_temps-u tile_20151119_2300.mp3?dl=0
flts


The DIY panel is a bit rough and unfinished...
Altitude909
quick legend check please:

pld
There are two outs labelled "3"...
mxmxmx
... also clock #4 is the DAC, if you wanted to specifically label that.


here's a diagram from github:



made me scratch my head the other day though. i was musing about the clock multiplication thing, but i'm not quite sure how to map it onto the existing UI. one way would be to simply merge it with the clock division mode, which probably isn't so very useful; alternatively, both division and multiplication could be made to work across all modes, in which case it would mean to either add a parameter item to each channel page (which i'd like to avoid) or re-purpose the left encoder (which isn't ideal either, because it'll involve even more long-presses (for mode selection)) -- thoughts?

@flts -- nice tune ... i really should figure out some solution for panels.
flts
mxmxmx wrote:
i was musing about the clock multiplication thing, but i'm not quite sure how to map it onto the existing UI. one way would be to simply merge it with the clock division mode, which probably isn't so very useful


I guess this might be the simple solution UI-wise - make fractional values under 1 available for the "division" parameter on screen for multiplication. Certainly convenient with minimal changes for UI, in case you get the division working first.

Quote:
alternatively, both division and multiplication could be made to work across all modes, in which case it would mean to either add a parameter item to each channel page (which i'd like to avoid) or re-purpose the left encoder (which isn't ideal either, because it'll involve even more long-presses (for mode selection)) -- thoughts?


This would actually be pretty cool and I was thinking of extending the firmware like that myself if I have the time at some point. When I was playing around with the module yesterday, I sort of wished I could trivially run one euclidean sequence on 1x clock and one for 2x or 4x or so. I don't know if it would be fiddly UI-wise though.

Quote:
@flts -- nice tune ... i really should figure out some solution for panels.


Thanks, it was more of an absend-minded jam but I ended up making about three or fours hours worth of variations on it while doing something else because I liked how it ended up sounding.

I do enjoy sawing and driling panels myself, just that right now I don't really have a quick access to a proper bench press etcetc. so I just use hand tools on my kitchen table which means accuracy isn't that great. I could've filed the screen window to look less wonky, but as it isn't really a functional issue I don't mind - maybe I'll eventually draw something equally wonky on the panel with thin paint markers so it'll sort of fit in.
Altitude909
wow. Dont edit panels early in the AM razz will fix

So what is the DAC out compared to the other clock outputs?
flts
Altitude909 wrote:
wow. Dont edit panels early in the AM razz will fix

So what is the DAC out compared to the other clock outputs?


The clock outputs are digital (0/1), the DAC is Teensy's internal 12 bit one which can also output random voltages etc. instead of just pulses like the other channels.
mxmxmx
flts wrote:
Altitude909 wrote:
wow. Dont edit panels early in the AM :P will fix

So what is the DAC out compared to the other clock outputs?


The clock outputs are digital (0/1), the DAC is Teensy's internal 12 bit one which can also output random voltages etc. instead of just pulses like the other channels.


yep, that's that. presently, there's just two modes: "binary" and "random", where random is random, and binary is a sequencer type thing, which tracks the clock state (clock 1 = MSB ... clock 6 = LSB).

meanwhile, here's a first stab at clock mulitplication. it's a bit of a hack but it seems to work, more or less. will need quite a bit of fine-tuning though, i broke various things in the process (the internal clock and, chances are, the store-settings stuff).

basically, the way it works is: there's two menu pages now for the left encoder (long press to toggle the page); the one page allows multiplying the incoming clock by 2, 4, 8 and 16 (that's a per channel setting), resolution of the underlying timer is 25 usec. the other page is for mode selection, which works as before.
flts
I've been using the module as the timing / trigger core for pretty much everything I've done with the euro modular for the past two months and have started getting ideas to my head about things that could be added or improved for my own purposes...

... thus I just wanted to quickly query what the dev status is. In case I start working on some additional modes / features, should I try building them on top of temps_utile or temps_utile_mult code (my module is still running the standard non-multiplier code) and are there any bugs I should look out for / try to fix during the process?
mxmxmx
flts wrote:

... thus I just wanted to quickly query what the dev status is. In case I start working on some additional modes / features, should I try building them on top of temps_utile or temps_utile_mult code (my module is still running the standard non-multiplier code) and are there any bugs I should look out for / try to fix during the process?


as you prefer. i must admit i haven't extensively used/tested the multiplying version myself (due to adverse work/life balance), but it shouldn't be entirely misdirected; the timer stuff is somewhat gleaned from the SCM. i wasn't too happy though with the way it worked out in terms of the UI. in other words: dev status is not very active right now; and it's always been the somewhat ugly stepsister of the O+C module, i suppose.

that said, over the last few weeks pld massively overhauled the core of O+C code, display drivers and all; lots of those enhancements* should carry over to this module, but it'll involve some effort. you can take a peek here.

* edit: the most interesting parts should be the display driver. it's using DMA now and rendering is split up into smaller bits; and there might be some menu features in there which could be of use in a clock sequencer scenario, too. generally speaking though, the display driver is far less mission critical in this case; it's just some GPIO and the onboard DAC that need to be updated in the ISR, there's no sharing of the SPI bus (as with O+C). in the multiplying version i had moved the update outside the ISR, i forgot why; it probably should be put back in. the core ISR (in the multiplying version) runs at 40kHz, it should be able to cope.
djamsia
Hello!!!
I have a problem with my temps-utile !!!
when I turn the image does not appear the 6 blocks in the OLED, however, get a bunch of stars of death, starwars kind !!!!

upload a couple of photos, if anyone can see a problem (PCB, OLED) or a possible clue.
Afotunadamente my ornament + crime, it runs smoothly ...
Thank you



mxmxmx
djamsia wrote:
Hello!!!
I have a problem with my temps-utile !!!
when I turn the image does not appear the 6 blocks in the OLED, however, get a bunch of stars of death, starwars kind !!!!

upload a couple of photos, if anyone can see a problem (PCB, OLED) or a possible clue.
Afotunadamente my ornament + crime, it runs smoothly ...


mmh, stars of death are not good. have you uncommented this line in u8g_teensy_14.cpp?
djamsia
yes i have uncommented..

//#define _TEMPS_UTILE_REV

will review hardware...
mxmxmx
djamsia wrote:
yes i have uncommented..

//#define _TEMPS_UTILE_REV

will review hardware...


ok, just to make sure: you have to uncomment two lines; the one in the display driver; and one in the main sketch.

as for the hardware, there's very little that actually could go wrong. there's just the SPI signals going straight from the MCU to the display header (digital pins 10, 11, 14), plus two auxiliary ones, D/C (9) and RST (4). and 3v3, which comes from the 78L33. you may want to try reflow the headers, and double-check the voltage, but it looks fine.

since you have a working o+c, have you tried swapping the OLED, just to rule that out?

fwiw, just to get the firmware out of the way, here's the hex:
djamsia
OK ... Thank you, my temps utile has left the dark side and has come to life.
I needed to define in the sketch too...

I hope to contribute something to this group in the future.



mxmxmx
djamsia wrote:
OK ... Thank you, my temps utile has left the dark side and has come to life.


cool, glad it's working.

apropos coming to life ... you should also check out the new and vastly improved o+c pre-beta firmware, it's not quite there yet but mostly usable.

as for your (pm) question, i don't have any spare pcbs at the moment except o+c. IIRC, bezier ordered a few eurotrash mk2, so maybe you can get one from him. (see the eurotrash thread, at the very bottom)
mr.sibs
Another working clocks here, thanks mxmxmx for the support and the great modules
flts
handed over mine to a friend as an abstract data octocontroller appeared in trade and that will have to do for now... i still have a pcb, a display and a spare teensy though, so will probably build myself another soon.
edwinm
If anyone has a spare board please let me know!
puzo
Hi. Does this suffer from the 1.3 oled shortage and do we anticipate the 1.4" adapted board from the OC to work?
Altitude909
puzo wrote:
Hi. Does this suffer from the 1.3 oled shortage and do we anticipate the 1.4" adapted board from the OC to work?


It looks like they are back, couple places on ebay have them. I struck out on Ali, they took my money and never sent anything (2 places actually)
mxmxmx
puzo wrote:
Hi. Does this suffer from the 1.3 oled shortage and do we anticipate the 1.4" adapted board from the OC to work?


yes and yes. it's the same display/pinout/driver. it'll take a while until everything is confirmed, including the panel, which will need adjustment (ie the cut-out)


Altitude909 wrote:


It looks like they are back, couple places on ebay have them.


really? i only seem to find 0.96" (with 7 pins, some of them with matching pinout) and a bunch of 1.3" ones, but with a different pinout (6 pins: VCC - GND - SCK - DATA - CS - D/C). those won't work; the CS, D/C stuff could be fixed easily enough in the firmware, but VCC and GND don't match.
puzo
Cheers, that's great, to the project and the adjustments to keep it alive. Guess I shouldn't take so long to get to my boards. I havnt got a panel yet so ok there.
Altitude909
grr.

didnt catch the wrong pinout on the others.

Anyone have a spare display they want to get rid of in the US?
sammy123
Raph let me check this evening. If I have two I'd be happy to send you one. I want to say I bought an ebay one a year or so ago and an adafruit one as well.
Altitude909
Cool, IIRC, the Adafruit was the 4 pin and I need the 7 pin..

On a related topic, what's the deal with 6pin vs 7pin? Cant I just run wires to change the pinout?
mxmxmx
Altitude909 wrote:

On a related topic, what's the deal with 6pin vs 7pin? Cant I just run wires to change the pinout?


adafruit has yet another pinout. and is sold out, too.

as for 6 vs 7 pin, some of those boards have a/the reset signal broken out, some of them don't. in as much those 6 pin ones do exist, i assume the reset signal is not absolutely needed (it certainly doesn't get deployed very much, except during initialisation). but i haven't ever tried and can't try now (ie what happens when commenting the reset stuff out). i'd assume it'll be fine; other than being more messy, running wires to the respective signals will be ok, of course.
sammy123
Actually looking closer I think my adafruit display was the 128x32 for the eurotrash. So I don't think I have a spare.
Altitude909
So what's the story about just making our own boards?

These displays are $5 from Future

http://www.futureelectronics.com/en/Technologies/Product.aspx?ProductI D=UG2864KLBLG01WISECHIPSEMICONDUCTORINC3048743&IM=0
mxmxmx
Altitude909 wrote:
So what's the story about just making our own boards?

These displays are $5 from Future


yeah, i was considering using bare 1.3" and simply make the necessary modifications to the adafruit board (.brd file) (ie basically just move the header pins around), but i couldn't find a reliable-looking source for the OLEDs (Future also says stock: 0)

i'm currently waiting for one of these. and this:




(8 pins because of O+C, the 8th pin is pulled high so the MCU can detect which OLED is being used. or at least that's the plan.)

the 1.5" ones are not as cheap, but they're available. and they come with a ZIF connector, which i figured will be easier to handle than the FPC connectors on the 1.3" ones.

in principle it looks entirely doable though; basically all that needs to go on the board is a few passives and a 3.3V/12V step up converter, such as this..
Altitude909
Sweet. So just rework the adafruit for the right pinout and it should work? I have a pile of ones that are wrong pinout that I can just rework..
mxmxmx
Altitude909 wrote:
Sweet. So just rework the adafruit for the right pinout and it should work? I have a pile of ones that are wrong pinout that I can just rework..


yep, it should. this one doesn't even need 12V. there's some stuff on there not needed (5v -> 3v3 level shifting, 3v3 local regulation, i2c option), so things could be simplified quite a bit, but re-arranging the pins should be all that's needed to make it work. basically: GND - 3v3 - D0 (SCK) - D1 (DATA) - RST - D/C - CS rather than DATA - SCK - D/C - RST - CS - 3v3 - 5v - GND
Altitude909
Are the diodes needed on the CS/RST/DC lines?
mxmxmx
Altitude909 wrote:
Are the diodes needed on the CS/RST/DC lines?


no, i don't think. i'd probably keep the pull-up resistors on CS, RST and DC, most of the rest can go:


Altitude909
Hows this look:



Altitude909
Ok,

Did some testing on the boards that I have here removing and re-soldering the displays to their respective boards and its a snap. Remove with hot air, solder back in place with iron. No problems. Polyimide is some cool shit for sure, seems crazy to be soldering metalized plastic (I didnt even turn the iron down, set at 370 C) but it works like a charm. I tried drag soldering at first but that made a mess but reworked it pin by pin and it looks as good as a hot bar with no damage
mxmxmx
Altitude909 wrote:
Hows this look:


cool, looking good.

except, you'd either have to get rid of the 8th pin or move the header slightly to the right, otherwise the panel cut-out will be off a few millimeters, because it expects those 7 pin OLEDs (which have the 7 pin header centred).

but the 8th pin ("MISO") is not really needed here. (it might be of some use for "ornament+crime", but the firmware defaults to SH1106, which is basically identical to SSD1306.) if you keep it, i'd pull it up via 10k rather than connect it to 3v3 though.

R2 i guess can go, too. just tie BS1 to GND.
mxmxmx
Altitude909 wrote:
Ok,

Did some testing on the boards that I have here removing and re-soldering the displays to their respective boards and its a snap. Remove with hot air, solder back in place with iron. No problems. Polyimide is some cool shit for sure, seems crazy to be soldering metalized plastic (I didnt even turn the iron down, set at 370 C) but it works like a charm. I tried drag soldering at first but that made a mess but reworked it pin by pin and it looks as good as a hot bar with no damage


oh, and that's good news. i've never tried but was mildly concerned it might not be feasible ...
Altitude909
Another possible source:
http://www.first-components.com/p/415/ug-2864kxxlg01
keninverse
I have the older Rev2 of the board...am I right to assume I can swap the 074 w/the rail to rail MCP6004 without any other component changes? Does this apply to the O+C as well?
mxmxmx
keninverse wrote:
I have the older Rev2 of the board...am I right to assume I can swap the 074 w/the rail to rail MCP6004 without any other component changes? Does this apply to the O+C as well?


no, they're not swappable! the ones with 6004 say '6004' on the silkscreen, on both pcbs.
keninverse
Oh I get it. I really need to think things through before posting stuff like this. The 6004 is running off the same supply as the teensy so that's why the schottky diodes are missing in the new Rev. It'll pop if I just drop it in the 074 spot. So would it be worth it to purchase the newer board?
mxmxmx
keninverse wrote:
So would it be worth it to purchase the newer board?


no, it's the same thing essentially; the version with the MCP6004 before the ADC is a bit simpler but not so much simpler.
flts
Well, seems my second Temps-Utile has a dead OLED. The Teensy powers up and lets reprogram itself just fine, and based on throwing manual gates to the unit it seems it does pass 1:1 clock from output 1 so it's working to some degree. It's just that there's nothing on the screen. The O+C I built in same session seems to work just fine.

Anything in particular I should check?
flts
To clarify, the O+C works with both displays, Temps-Utile with neither, so the problem is somewhere in Temps-Utile. As the Teensy seems to work just fine, it's assumingly not the Teensy, but either the software or connections somewhere in between display and the Teensy. Tried reflowing the obvious places and measuring continuity between Teensy pins and board, to no avail.

Furthermore, all the OLED pins are connected to somewhere on the teensy, except VCC and GND which receive 3.3V as intended. Tried replacing the Teensy with one from O+C just for fun (I'm not sure if the pinout is even same), and the screen was still blank. Back to O+C board, works fine.

By quickly poking on the data lines with multimeter on frequency mode there's ~50Hz signal on the data lines and clock.
mxmxmx
flts wrote:
To clarify, the O+C works with both displays, Temps-Utile with neither, so the problem is somewhere in Temps-Utile. As the Teensy seems to work just fine, it's assumingly not the Teensy, but either the software or connections somewhere in between display and the Teensy. Tried reflowing the obvious places and measuring continuity between Teensy pins and board, to no avail.

Furthermore, all the OLED pins are connected to somewhere on the teensy, except VCC and GND which receive 3.3V as intended. Tried replacing the Teensy with one from O+C just for fun (I'm not sure if the pinout is even same), and the screen was still blank. Back to O+C board, works fine.

By quickly poking on the data lines with multimeter on frequency mode there's ~50Hz signal on the data lines and clock.


it's a software thing, most likely. have you had a blue pcb before? if not, make sure you uncomment the lines where it says #define _TEMPS_UTILE_REV (in the main sketch and u8g_teensy_14.cpp). or just pull the latest from github, the firmware should default to _TEMPS_UTILE_REV
flts
mxmxmx wrote:
it's a software thing, most likely. have you had a blue pcb before? if not, make sure you uncomment the lines where it says #define _TEMPS_UTILE_REV (in the main sketch and u8g_teensy_14.cpp). or just pull the latest from github, the firmware should default to _TEMPS_UTILE_REV


Okay, figured it out now, thanks a _lot_ for the pointer.

Explanation: the compile instructions say that one should copy the three libraries to arduino libraries dir. However, I had a version of u8g_teensy_14 that was copied either from earlier version of T-U firmware or O+C as I flashed that one at the same time (not sure which one it was).

Replacing the u8g_teensy_14 lib with the latest repository version fixed the problem instantly.

Edit: if anyone's interested, it was actually a bit more complex situation than that - I _had_ copied the latest repository versions of the libraries to OSX Arduino package's library directory, but turns out it was using the duplicate version from ~/Documents/Arduino/libraries/ which is the other place for library lookup. It was actually visible on the compile output but I didn't realize it actually would have mattered.
mxmxmx
flts wrote:


Okay, figured it out now, thanks a _lot_ for the pointer.


ok, cool. and sorry for the hassle. i shouldn't have changed the pins in the first place (i did so because in theory the current version will make using DMA easier, but i didn't even get around to trying ... )
flts
^- No problem, at least I'll remember to check both of the library locations next time - I was on the right track but got foiled by Arduino's directory lookup system.



Looks like both of them live now at least, apologies for the crappy night cellphone camera picture. Will have to start packing up for a move tomorrow, and spend a bit of time testing and calibrating those before that.
bennelong.bicyclist
flts wrote:
^- No problem, at least I'll remember to check both of the library locations next time - I was on the right track but got foiled by Arduino's directory lookup system.



Looks like both of them live now at least, apologies for the crappy night cellphone camera picture. Will have to start packing up for a move tomorrow, and spend a bit of time testing and calibrating those before that.


Nice!

Slightly OT, but don't spend too much time trying to get the O+C gain calibration using the trimmers perfect on each channel, because the forthcoming enhanced firmware uses more detailed calibration settings (thanks to @pld), per channel, which makes the trimmer adjustment a bit less critical. You still need to get it roughly right using the trimmers, but don't spend hours going back-and-forward trying to get it exactly right.
mxmxmx
flts wrote:

Looks like both of them live now at least, apologies for the crappy night cellphone camera picture. Will have to start packing up for a move tomorrow, and spend a bit of time testing and calibrating those before that.


cool ... enjoy! are those geerscutting.com? (2nd o+c is on the way, btw ... and yeah, at this point, use the new+enhanced calibration stuff)
flts
Thanks - I did already install pld's & bennelong's beta firmware from the main repository's "dev" branch to the O+C in the picture. Also saw a mention in the actual O+C thread that the new software calibration will mean the trimmers will become "obsolete" and could be eventually replaced with (precision) resistors, but didn't really look at the whole calibration thing yet so good to know they can be just roughly adjusted to correct position (?) and then the actual calibration done with the sw process.

The panels are from Lasergist (which I assumed to be an US company but apparently is based in Greece). 1,5mm stainless steel. Feels pretty nice - of course the material is heavier and shinier than aluminum, is fingerprint magnet, and quality of work is a bit rough on the edges as expected.

& I'll inform my friend that the second O+C board is on its way, thanks smile
Altitude909
what driver is used with your displays? There are two different ones that are common and there needed to be some changes for Temps to work with the less common one (1206 vs 1106?)
flts
^- See my rambling and Max's suggestions above - managed to get it working simply by erasing / rewriting old versions of the libraries that were accidentally still lying in Arduino libraries directory after having compiled an old version of Temps-Utile months ago.

In the end I simply didn't realize that the TEMPS_UTILE_REV_ is / has to be defined somewhere in the libraries as well.

FWIW the displays I have both had (S)SH1106 controllers - I did try uploading a fw version with SSD1106 (?) driver mode enabled just in case but obviously that didn't help in this case...
Altitude909
Ah, the dreaded blue PCB. I share your pain Mr. Green
mxmxmx
Altitude909 wrote:
Ah, the dreaded blue PCB.


yeah, it's a bit annoying. though by now it should only trip up people having had the thing in their back-log for too long (= non-blue boards), or if they had previously build one, like flts.
mxmxmx
fyi --

here's a little preview of a fairly major firmware update. not quite there yet, but basically functional. (except no CV yet; and lots of little things to finetune, etc. *).

basically, it's a port of pld's engine / UI scheme for o_C.

... which has many benefits, most notably the thing can be clocked a good deal faster now, kHz rather than Hz:




(channel 1 (yellow) is in multiplier mode and XOR'd with channels 2,3 (blue/pink)

there's also some new things:

- multiplication/division per channel (available in all modes)
- new pattern editor mode (arbitrary patterns, 4-16 length. (works like the scale editor in o_C))
- improved LFSR (turing machine) mode for the DAC channel



(pattern editor)

* also i should say, as is, it won't work with the older pcb versions -- you'd have to adjust the GPIO for the outputs and display first (in TU_gpio.h)
Altitude909
mxmxmx wrote:
..
* also i should say, as is, it won't work with the older pcb versions -- you'd have to adjust the GPIO for the outputs and display first (in TU_gpio.h)


Elaborate?
Timmy
mxmxmx wrote:
fyi --

here's a little preview of a fairly major firmware update. not quite there yet, but basically functional. (except no CV yet; and lots of little things to finetune, etc. *).

basically, it's a port of pld's engine / UI scheme for o_C.

... which has many benefits, most notably the thing can be clocked a good deal faster now, kHz rather than Hz:

(channel 1 (yellow) is in multiplier mode and XOR'd with channels 2,3 (blue/pink)

there's also some new things:

- multiplication/division per channel (available in all modes)
- new pattern editor mode (arbitrary patterns, 4-16 length. (works like the scale editor in o_C))
- improved LFSR (turing machine) mode for the DAC channel



(pattern editor)

* also i should say, as is, it won't work with the older pcb versions -- you'd have to adjust the GPIO for the outputs and display first (in TU_gpio.h)


Nice! A veritable GateTempest in-the-making!
mxmxmx
Altitude909 wrote:
mxmxmx wrote:
..
* also i should say, as is, it won't work with the older pcb versions -- you'd have to adjust the GPIO for the outputs and display first (in TU_gpio.h)


Elaborate?


the latest (= 'blue') boards use a different set of pins for driving the OLED as well as for the clock outputs. i've just added the missing switch: simply uncomment line #8 in TU_gpio.h for the old (= yellow, green) version.

Timmy wrote:

Nice! A veritable GateTempest in-the-making!


yeah, still needs a bit of work. but already much better now and less confusing when operating the two modules side by side. the gate sequencers are very handy ...
thelizard
Any recommendations on the inductor? I can't figure out which of these I should go with, or if I should go for an 0805 package:
http://www.mouser.com/Passive-Components/Inductors/_/N-5gb4?P=1z0wricZ 1yzvlku&Keyword=10+uh+1206&FS=True

Also, any chance of a panel group-buy soon? I'm building this up simultaneously with an O+C and am almost finished with both.
Timmy
thelizard wrote:
Any recommendations on the inductor? I can't figure out which of these I should go with, or if I should go for an 0805 package:
http://www.mouser.com/Passive-Components/Inductors/_/N-5gb4?P=1z0wricZ 1yzvlku&Keyword=10+uh+1206&FS=True


I used Mouser part 81-LQH31MN100K03L
heapish
Where can I find a yellow pcb noises cart? Cheers
mxmxmx
heapish wrote:
Where can I find a yellow pcb noises cart?


you mean mouser cart? not that i know.

also: "yellow" as in pcb-with-TL074-and-bat54s diodes (should be easy to tell -- the diodes (sot-23-3) are right next to the teensy) or pcb-that-happens-to-be yellow (don't know, for instance, which colour was chosen for that recent group buy)? fwiw, the recent/up-to-date versions all use Futura for the "temps utile" label; anyways the differences are minimal, it's mainly TL074 vs MCP6004
heapish
mxmxmx wrote:
heapish wrote:
Where can I find a yellow pcb noises cart?


you mean mouser cart? not that i know.

also: "yellow" as in pcb-with-TL074-and-bat54s diodes (should be easy to tell -- the diodes (sot-23-3) are right next to the teensy) or pcb-that-happens-to-be yellow (don't know, for instance, which colour was chosen for that recent group buy)? fwiw, the recent/up-to-date versions all use Futura for the "temps utile" label; anyways the differences are minimal, it's mainly TL074 vs MCP6004

Sorry, auto correct. Its not in my hands yet, but was bought from you by someone else, traded for it.... Ok so I'm guessing the BOM is on github?
Timmy
One of two newly built TUs for my rack.

sanderr2
I'm having a bit of trouble finding the firmware in github https://github.com/mxmxmx/temps_utile-/wiki/firmware

I've downloaded the three libraries and put them in the right place but where is the actual file to compile / upload to the teensy?

Sorry if I'm being dumb! Rob

PS Those acrylic panels look fantastic - how do I get my hands on some (or do I have to make them?!)
Altitude909
sanderr2 wrote:
I'm having a bit of trouble finding the firmware in github https://github.com/mxmxmx/temps_utile-/wiki/firmware

I've downloaded the three libraries and put them in the right place but where is the actual file to compile / upload to the teensy?

Sorry if I'm being dumb! Rob

PS Those acrylic panels look fantastic - how do I get my hands on some (or do I have to make them?!)


You have to build it, there is no precompiled hex for TU afaik
mxmxmx
Altitude909 wrote:
sanderr2 wrote:
I'm having a bit of trouble finding the firmware in github https://github.com/mxmxmx/temps_utile-/wiki/firmware

I've downloaded the three libraries and put them in the right place but where is the actual file to compile / upload to the teensy?

Sorry if I'm being dumb! Rob

PS Those acrylic panels look fantastic - how do I get my hands on some (or do I have to make them?!)


You have to build it, there is no precompiled hex for TU afaik


yep, as altitude909 says -- that page is only meant as a quick how-to (compile the firmware); there's no pre-compiled version.

just follow the steps and make sure to compile with "120MHz (overclock)"; a more detailed version of this can be found on the o_C repository/wiki; it's basically the same, except you have to include different libraries. the actual code is in the folder called "soft"; alternatively, you can try the (incomplete) dev branch, which has fewer dependencies and should be more straightforward to compile.
heapish
Temps Utile Cart minus OLED and Jacks. PLEASE someone check parts and quantities. I'm a mouser cart noob.

I have used these replacements, is this ok?
TL074CDRG4 instead of TL074
0.47uf 50v instead of 35v

https://www.mouser.co.uk/ProjectManager/ProjectDetail.aspx?AccessID=82 775c3e45


UPDATED VERSION
http://www.mouser.com/ProjectManager/ProjectDetail.aspx?AccessID=f5651 ed713
Timmy
sanderr2 wrote:
PS Those acrylic panels look fantastic - how do I get my hands on some (or do I have to make them?!)


You have to have them cut. I use a local laser cutting service, but Ponoko or similar will also do them. Be warned, everything only just fits when 3mm acrylic is used for the panel - the Thonkiconn jack nuts only just thread on, and the encoders need to be soldered from the top of the PCB, and low-profile sockets are essential for the OLED. However, it does all fit. I can send the SVG files to Max for inclusion in the TU repo.
mxmxmx
heapish wrote:
Temps Utile Cart minus OLED and Jacks. PLEASE someone check parts and quantities. I'm a mouser cart noob.

I have used these replacements, is this ok?
TL074CDRG4 instead of TL074
0.47uf 50v instead of 35v

https://www.mouser.co.uk/ProjectManager/ProjectDetail.aspx?AccessID=82 775c3e45


quick look suggests, looks ok. you'll need 2x TL074 though!

you probably could have just copied most part numbers from the o_C BOM, except the few NP0 caps (1n, 3n3, 18n) and a couple of resistors, it's fairly identical. and same caveat applies, personally i wouldn't buy the sockets/headers for the teensy at mouser...
sanderr2
mxmxmx wrote:
Altitude909 wrote:
sanderr2 wrote:
I'm having a bit of trouble finding the firmware in github https://github.com/mxmxmx/temps_utile-/wiki/firmware

I've downloaded the three libraries and put them in the right place but where is the actual file to compile / upload to the teensy?

Sorry if I'm being dumb! Rob

PS Those acrylic panels look fantastic - how do I get my hands on some (or do I have to make them?!)


You have to build it, there is no precompiled hex for TU afaik


yep, as altitude909 says -- that page is only meant as a quick how-to (compile the firmware); there's no pre-compiled version.

just follow the steps and make sure to compile with "120MHz (overclock)"; a more detailed version of this can be found on the o_C repository/wiki; it's basically the same, except you have to include different libraries. the actual code is in the folder called "soft"; alternatively, you can try the (incomplete) dev branch, which has fewer dependencies and should be more straightforward to compile.




Thanks guys.
I've downloaded the O&C repository and made the files available to the Temps Utile compile however it's failing to find u8g.h which doesn't seem to exist anywhere. Is this file the same as u8glib.h?
sanderr2
Timmy wrote:
sanderr2 wrote:
PS Those acrylic panels look fantastic - how do I get my hands on some (or do I have to make them?!)


You have to have them cut. I use a local laser cutting service, but Ponoko or similar will also do them. Be warned, everything only just fits when 3mm acrylic is used for the panel - the Thonkiconn jack nuts only just thread on, and the encoders need to be soldered from the top of the PCB, and low-profile sockets are essential for the OLED. However, it does all fit. I can send the SVG files to Max for inclusion in the TU repo.


Thanks Timmy- there don't seem to be any TU panels out there to buy so making my own would be a great option. Plus they look v. cool.
heapish
mxmxmx wrote:
heapish wrote:
Temps Utile Cart minus OLED and Jacks. PLEASE someone check parts and quantities. I'm a mouser cart noob.

I have used these replacements, is this ok?
TL074CDRG4 instead of TL074
0.47uf 50v instead of 35v

https://www.mouser.co.uk/ProjectManager/ProjectDetail.aspx?AccessID=82 775c3e45


quick look suggests, looks ok. you'll need 2x TL074 though!

you probably could have just copied most part numbers from the o_C BOM, except the few NP0 caps (1n, 3n3, 18n) and a couple of resistors, it's fairly identical. and same caveat applies, personally i wouldn't buy the sockets/headers for the teensy at mouser...


Thats what I did and used the descriptions of similar parts to find the missing ones wink
Where would you get the Teensy? Oshpark? isnt that from the US, which would mean taxes if you are in Europe? Cheers for the help.

Updated cart with 2nd TL074 added
http://www.mouser.com/ProjectManager/ProjectDetail.aspx?AccessID=f5651 ed713
Timmy
sanderr2 wrote:
Timmy wrote:
sanderr2 wrote:
PS Those acrylic panels look fantastic - how do I get my hands on some (or do I have to make them?!)


You have to have them cut. I use a local laser cutting service, but Ponoko or similar will also do them. Be warned, everything only just fits when 3mm acrylic is used for the panel - the Thonkiconn jack nuts only just thread on, and the encoders need to be soldered from the top of the PCB, and low-profile sockets are essential for the OLED. However, it does all fit. I can send the SVG files to Max for inclusion in the TU repo.


Thanks Timmy- there don't seem to be any TU panels out there to buy so making my own would be a great option. Plus they look v. cool.


These panels are also very nice, and they are not too thick. I think there are some available now if you're quick: https://www.muffwiggler.com/forum/viewtopic.php?t=164637
Timmy
sanderr2 wrote:
mxmxmx wrote:
Altitude909 wrote:
sanderr2 wrote:
I'm having a bit of trouble finding the firmware in github https://github.com/mxmxmx/temps_utile-/wiki/firmware

I've downloaded the three libraries and put them in the right place but where is the actual file to compile / upload to the teensy?

Sorry if I'm being dumb! Rob

PS Those acrylic panels look fantastic - how do I get my hands on some (or do I have to make them?!)


You have to build it, there is no precompiled hex for TU afaik


yep, as altitude909 says -- that page is only meant as a quick how-to (compile the firmware); there's no pre-compiled version.

just follow the steps and make sure to compile with "120MHz (overclock)"; a more detailed version of this can be found on the o_C repository/wiki; it's basically the same, except you have to include different libraries. the actual code is in the folder called "soft"; alternatively, you can try the (incomplete) dev branch, which has fewer dependencies and should be more straightforward to compile.


Thanks guys.
I've downloaded the O&C repository and made the files available to the Temps Utile compile however it's failing to find u8g.h which doesn't seem to exist anywhere. Is this file the same as u8glib.h?


As Max suggests, use the dev branch in that repo - it uses a custom screen driver, not the u8g library. All further development will be done on that branch, so might as well use it, as well as it being easier to set up.
mxmxmx
Timmy wrote:

I've downloaded the O&C repository and made the files available to the Temps Utile compile however it's failing to find u8g.h which doesn't seem to exist anywhere. Is this file the same as u8glib.h?


oh, sorry if i was unclear. i just meant the o_C how-to. the actual libraries/files you need to include are the ones from the temps utile repository (rotaryplus; spi4teensy3_14; and u8g_teensy_14). if you put those three into your "library" folder, it should compile fine. u8g.h is u8g_teensy_14/utility/

or use the dev branch, as mentioned. the steps will be the exact same ones as with o_C
sanderr2
Timmy wrote:
sanderr2 wrote:
Timmy wrote:
sanderr2 wrote:
PS Those acrylic panels look fantastic - how do I get my hands on some (or do I have to make them?!)


You have to have them cut. I use a local laser cutting service, but Ponoko or similar will also do them. Be warned, everything only just fits when 3mm acrylic is used for the panel - the Thonkiconn jack nuts only just thread on, and the encoders need to be soldered from the top of the PCB, and low-profile sockets are essential for the OLED. However, it does all fit. I can send the SVG files to Max for inclusion in the TU repo.


Thanks Timmy- there don't seem to be any TU panels out there to buy so making my own would be a great option. Plus they look v. cool.


These panels are also very nice, and they are not too thick. I think there are some available now if you're quick: https://www.muffwiggler.com/forum/viewtopic.php?t=164637



Yes - I registered my interest for these panels a couple of weeks ago but haven't heard anything back yet!
sanderr2
mxmxmx wrote:
Altitude909 wrote:
sanderr2 wrote:
I'm having a bit of trouble finding the firmware in github https://github.com/mxmxmx/temps_utile-/wiki/firmware

I've downloaded the three libraries and put them in the right place but where is the actual file to compile / upload to the teensy?

Sorry if I'm being dumb! Rob

PS Those acrylic panels look fantastic - how do I get my hands on some (or do I have to make them?!)


You have to build it, there is no precompiled hex for TU afaik


yep, as altitude909 says -- that page is only meant as a quick how-to (compile the firmware); there's no pre-compiled version.

just follow the steps and make sure to compile with "120MHz (overclock)"; a more detailed version of this can be found on the o_C repository/wiki; it's basically the same, except you have to include different libraries. the actual code is in the folder called "soft"; alternatively, you can try the (incomplete) dev branch, which has fewer dependencies and should be more straightforward to compile.



Thanks max - I used the development branch and it compiled fine. My Temps Utile and Ornament & Crime are now up and running!
Timmy
sanderr2 wrote:
Timmy wrote:
These panels are also very nice, and they are not too thick. I think there are some available now if you're quick: https://www.muffwiggler.com/forum/viewtopic.php?t=164637



Yes - I registered my interest for these panels a couple of weeks ago but haven't heard anything back yet!


The panels take several weeks to arrive from the PCB fabricator. They arrived in Australia a few days ago. I'm sure you'll be contacted in due course.
sanderr2
Timmy wrote:
sanderr2 wrote:
Timmy wrote:
These panels are also very nice, and they are not too thick. I think there are some available now if you're quick: https://www.muffwiggler.com/forum/viewtopic.php?t=164637



Yes - I registered my interest for these panels a couple of weeks ago but haven't heard anything back yet!


The panels take several weeks to arrive from the PCB fabricator. They arrived in Australia a few days ago. I'm sure you'll be contacted in due course.


Thanks Tim - as if by magic an email from Gareth at Oscillosaurus dropped into my inbox straight after your post!
mxmxmx
sanderr2 wrote:

Thanks max - I used the development branch and it compiled fine. My Temps Utile and Ornament & Crime are now up and running!


cool, you'll note there's still a few bits missing; in particular, the CV stuff (there's a to-do list in CLK_APP.ino).... soon, I hope. in the meantime, I can put up the hex file for the old firmware when I get back
sanderr2
Thanks max - a hex file for the old firmware would be great for other relative noobs like me. Cheers, Rob
mxmxmx
sanderr2 wrote:
Thanks max - a hex file for the old firmware would be great for other relative noobs like me. Cheers, Rob


sure, here we go
sanderr2
Great - thanks Max - really appreciate that! Have a great weekend. Cheers, Rob
Rowan
Im going order some PCBs in the next couple of days from Seed, unless some tells me there is a good reason not to. I've never order PCBs directly from a manufacturer before. Is there anything I need to know before I place my order?

I'm open to suggestions regarding who I use for manufacturing, I want a good cost/quality ratio therefore I don't expect a quick turn around.
mxmxmx
Rowan wrote:
Im going order some PCBs in the next couple of days from Seed, unless some tells me there is a good reason not to. I've never order PCBs directly from a manufacturer before. Is there anything I need to know before I place my order?


no, you just upload the gerbers / the .zip file. i haven't ordered from Seeed in a long time but figure it's all the same; i tend to use elecrow. they also have an ENIG option, which costs slightly more, but not much.
keninverse
I have an older yellow board I'm building up and wanted to confirm some parts. Looks like there are two diodes at the bottom corner of the board. What are placed here? Also there's a LM4132 outline silkscreened on the board. Do I need to place this or can this be left off?
mxmxmx
keninverse wrote:
I have an older yellow board I'm building up and wanted to confirm some parts. Looks like there are two diodes at the bottom corner of the board. What are placed here? Also there's a LM4132 outline silkscreened on the board. Do I need to place this or can this be left off?


just leave off the LM1432 part and jumper the 3v3 pad right above it. for the diodes, use 33k or if you have any, use a Schottky diode ('minimelf'), either will protect the transistors from too much V_ebo.

the quad op amp is a TL074; the four sot-23 parts in vicinity to the teensy are bat54s (mouser # 78-BAT54S-G3-08). you have to connect the pads that say '28' and '29' to the eponymous SMD pads on the bottom of the teensy (which is a bit of a nuisance, which is why i've changed it)

other than that, you can follow the build guide for the later version. the only thing to keep in mind is that, when compiling the firmware, you have to comment out the lines that say #define _TEMPS_UTILE_REV (in temps_utile.ino and u8g_teensy_14.cpp or, if you want to try the dev firmware, in TU_gpio.h)
keninverse
Thanks for all the details Max. Will SM5817s work to protect the transistors or should I just use resistors? I know I have both of those lying around.
mxmxmx
keninverse wrote:
Will SM5817s work to protect the transistors or should I just use resistors? I know I have both of those lying around.


just use the resistor, much cheaper!
thelizard
Is there an estimate on when the revised firmware will be released? Is there any way that I can help out?
Timmy
thelizard wrote:
Is there an estimate on when the revised firmware will be released? Is there any way that I can help out?


I doubt that an estimate exists, and if it does, it is almost certainly wrong.

However I'm sure Max would be happy to consider pull requests if you want to work on the code. There are two classes of things that could be done:

a) adding CV control to appropriate parameters for the existing functions in the sole app in TU at present, along the lines that input CVs can be mapped to parameters in many of the O&C apps. However, check with Max, because he may already have done some of that but not pushed it to the repo.

b) write a new app, using the app framework (written by Patrick Dowling) - see the O&C code to see how new apps are added - it's a nice, clean interface. Just copy the existing app as a scaffold - at least, that's what I plan to do. Because apps are stand-alone, each one is almost a greenfield site, although sticking to the UI conventions imposed by the app framework is a good idea. Maybe check with Max to make sure effort is not being duplicated, or just mention intended work in this thread so everyone is aware, just to avoid duplicated effort. There's room for a lot more apps!
mxmxmx
Timmy wrote:
thelizard wrote:
Is there an estimate on when the revised firmware will be released? Is there any way that I can help out?


I doubt that an estimate exists, and if it does, it is almost certainly wrong.


everything is wrong, but yeah, i don't know when; as Tim said, it's mainly the CV stuff that's missing (and lots of little details), and i didn't get round to doing much about it in the last few weeks. as for other 'apps' i don't have any plans or ideas for that matter ...
heapish
mxmxmx wrote:
heapish wrote:
Where can I find a yellow pcb noises cart?


you mean mouser cart? not that i know.

also: "yellow" as in pcb-with-TL074-and-bat54s diodes (should be easy to tell -- the diodes (sot-23-3) are right next to the teensy) or pcb-that-happens-to-be yellow (don't know, for instance, which colour was chosen for that recent group buy)? fwiw, the recent/up-to-date versions all use Futura for the "temps utile" label; anyways the differences are minimal, it's mainly TL074 vs MCP6004


This. Got it off a fella called Romain Vanbruggen who says he got it off you. Have you a BOM for it that I can compare to the newer one?
Thankyou
mxmxmx
heapish wrote:

Have you a BOM for it that I can compare to the newer one?


see here.


i also have more of these, should you prefer:

heapish
mxmxmx wrote:
heapish wrote:

Have you a BOM for it that I can compare to the newer one?


see here.


i also have more of these, should you prefer:


What's the difference? Has that one more compatibility for future plans? How much posted to the UK?
Sinamsis
Just bought one of these (built, not a DIYer). Mainly posting so I can be in the loop when new firmware is available. Thanks to all the folks involved, this looks like it will be an amazing little device and something I've been looking for in euroworld. Also commissioned an O and C. Can't wait to get these two together!
Sinamsis
Just bought one of these (built, not a DIYer). Mainly posting so I can be in the loop when new firmware is available. Thanks to all the folks involved, this looks like it will be an amazing little device and something I've been looking for in euroworld. Also commissioned an O and C. Can't wait to get these two together!
adnauseam
Just an after thought - not meaning to be an arse.

Had you placed all six jacks on each row in a line the same panel could have been used for O_C and Temps Utile

d'oh!
Sinamsis
adnauseam wrote:
Just an after thought - not meaning to be an arse.

Had you placed all six jacks on each row in a line the same panel could have been used for O_C and Temps Utile

d'oh!


That would confuse the separation of inputs and outputs (different between the two modules) I believe.
mxmxmx
adnauseam wrote:
Just an after thought - not meaning to be an arse.

Had you placed all six jacks on each row in a line the same panel could have been used for O_C and Temps Utile



i did it on purpose ("functional grouping") ... but yeah, i do regret (somewhat) not having evenly spaced the jacks; mainly though because it wouldn't hurt to have a little more space in between the jacks, i don't think using the same panel would have worked (?) (4 CV out vs 6 clock out, etc)


heapish wrote:

What's the difference? Has that one more compatibility for future plans?


not much. the revision was entirely about convenience in putting the thing together; ie there's no functional difference or compatibility issues, the later versions just use a different set of pins, which makes it _slightly_ more straightforward to build (in that it doesn't use those SMD pads at the bottom of the dev board).
heapish
mxmxmx wrote:

not much. the revision was entirely about convenience in putting the thing together; ie there's no functional difference or compatibility issues, the later versions just use a different set of pins, which makes it _slightly_ more straightforward to build (in that it doesn't use those SMD pads at the bottom of the dev board).

Cheers for the pm.
Does the old one still need trimmers and 49k9 resistors since the software change for the encoder reverse?
I'll sleep on it, just trying to get stuff together ready for my next order/free day
mxmxmx
heapish wrote:
Does the old one still need trimmers and 49k9 resistors since the software change for the encoder reverse?


no, it doesn't need the trimmer. (nothing to do the with encoders, btw. if those happen to be reverse, you'd have to change it by hand. the temps utile firmware is not nearly as sophisticated as o_C, yet). i've added a note re: old PCBs in the build guide, but it's essentially the same procedure except you use a different op amp.
keninverse
Question about the firmware in the dev branch. Is the UI the same as the older firmware? And are the operations essentially the same (e.g. long pressing buttons). I only had a few minutes to play around with the module once programmed and it looks like it seems to be working properly. Just wondering if I missed something like a basic user manual in this thread or on gitbub.
mxmxmx
keninverse wrote:
Question about the firmware in the dev branch. Is the UI the same as the older firmware? And are the operations essentially the same (e.g. long pressing buttons).


there's no documentation for the dev branch yet; the short answer is: no, it's somewhat different: it works much the same as the quad quantizer in ornament+crime now, which is/was the main motivation in starting it, ie homogenizing the UI. CV isn't implemented yet, so all of that (mapping CV inputs to parameters etc) doesn't work. as is, the main difference is the left encoder is used for channel selection in the dev branch version, ie rather than for selecting the channel mode (random, LFSR, euclidian, sequencer, etc); i'm not sure yet i'll keep it that way. feedback appreciated.
heapish
mxmxmx wrote:
heapish wrote:
Does the old one still need trimmers and 49k9 resistors since the software change for the encoder reverse?


no, it doesn't need the trimmer. (nothing to do the with encoders, btw. if those happen to be reverse, you'd have to change it by hand. the temps utile firmware is not nearly as sophisticated as o_C, yet). i've added a note re: old PCBs in the build guide, but it's essentially the same procedure except you use a different op amp.


Sooooo, yellow,

I need an extra 4x 100k to go in place of 49k9
Dont need to order the optional LM4040-2.5 (SOT-23)

Yellow notes q's
Do i need 4 extra BAT54S (instead the diodes at the bottom of the board) or are these the ones already in the the yellow bom?
The pads numbered 28 and 29 on the board are jumpered to 28 and 29 on the underside of the teensy? I ask this as the note for the blue board "simply ignore the pads labelled 29 and 79L05; none of this is required."
Which leads me to do the notes for the blue also apply to the yellow, like you said ommit trimmer and change the 49k9 resistors?

Hope all that made sense? (sorry for all the questions, new to using github)
mxmxmx
heapish wrote:


Sooooo, yellow,



... i've added more info on github. clearer now?

in short:


I need an extra 4x 100k to go in place of 49k9?

yes

Dont need to order the optional LM4040-2.5 (SOT-23)?

no, it's not needed

Do i need 4 extra BAT54S?

yes, you need exactly 4

The pads numbered 28 and 29 on the board are jumpered to 28 and 29 on the underside of the teensy?

yes, as i said, the pin usage is different. you also need the 79L05
heapish
Thankyou for your time smile
keninverse
I had a little more time playing with this tonight and I'm totally impressed. The UI is intuitive and it makes sense to keep the left encoder to modify the mode. So I take it there's no internal clock? Having an internal clock with bpm faculties seems pretty cool. I planned on using this as a main clock source so I may go back to the older firmware but having both multiplying and division properties is really nice. I suppose a lot of the branches would need to be reference an internal clock if this was added. At any rate great module max.
mxmxmx
cool, thanks for trying ---

keninverse wrote:
So I take it there's no internal clock?


there is, but no corresponding menu items (currently, the way it works is the incoming trigger frequency sets the internal timer overflow value; that value could alternatively be set by the encoder). not a big deal, and it's on my list, mainly i wasn't sure how to deal with it UI-wise; there's a dummy/placeholder in 'clock src' (none); i'm tending toward 'clock src' -> TR1, TR2, GLOBAL, CHANNEL (or whatever fits on the display), where the latter two would both be internal timers, one slaved to some global speed setting, the other local. (?)
keninverse
Awesome good to hear it'll be the internal clock will be supported.
Quote:
(currently, the way it works is the incoming trigger frequency sets the internal timer overflow value; that value could alternatively be set by the encoder).

So dial in for frequency or physically pressing the encoder switch as in a tap tempo?

Quote:
i'm tending toward 'clock src' -> TR1, TR2, GLOBAL, CHANNEL (or whatever fits on the display), where the latter two would both be internal timers, one slaved to some global speed setting, the other local. (?)


this sounds great but just to clarify this would mean at clock source local there would be 6 independent clocks? thanks for the time!
heapish
In the bom the through hole caps have RM written after them, is that lead spacing?
mxmxmx
heapish wrote:
In the bom the through hole caps have RM written after them, is that lead spacing?


yep, Rastermaß -- take a look at the ornament+crime BOM, the parts are mostly the same, +/- some passives.
mxmxmx
heapish wrote:
In the bom the through hole caps have RM written after them, is that lead spacing?


yep, Rastermaß -- take a look at the ornament+crime BOM, the parts are mostly the same, +/- some passives.
heapish
mxmxmx wrote:
heapish wrote:
In the bom the through hole caps have RM written after them, is that lead spacing?


yep, Rastermaß -- take a look at the ornament+crime BOM, the parts are mostly the same, +/- some passives.

Yep, i did that smile Thankyou
toneburst
@mxmxmx hi, do you have any Temps Utile PCBs available at the moment?
I like the O+C so much I want to get it's brother, too wink

Cheers,

a|x
mxmxmx
toneburst wrote:
@mxmxmx hi, do you have any Temps Utile PCBs available at the moment?
I like the O+C so much I want to get it's brother, too ;)


i do, though i should note the brother is still fairly retarded. there's a branch which will make it more O+C like, eventually; i didn't get to spend much time on this or anything lately...
toneburst
That's cool. May I order one?
When you say 'retarded', do you mean in terms of the firmware?
From the description, it sounds to be pretty useful, though.

a|x
mxmxmx
toneburst wrote:
That's cool. May I order one?


sure, i'll pm you. and yes, in terms of firmware. the TU firmware as is (written mainly by me) is nowhere as sophisticated as O+C (written mainly not by me, but pld); it works ok, but it could work better and the UI concept is different now (from O+C) which is confusing.
toneburst
I see. Well, hopefully the two modules will converge eventually.
I have an idea for an app for it, as it happens, if the same kind of application-switching setup as the O+C is implemented in the future.

a|x
audiohawk
PCBs arrived safe. Thank you for your work we're not worthy
mxmxmx
toneburst wrote:
I see. Well, hopefully the two modules will converge eventually.
I have an idea for an app for it, as it happens, if the same kind of application-switching setup as the O+C is implemented in the future.


that's the plan, there's the dev branch already which is based on the O+C code and is half-way there; it still lacks CV mapping. anyways, the same mode switching is/will be available, and since everything is combined in one app, there's plenty of space left for other apps.
toneburst
Sounds good!
Looking forward to assembling mine.

a|x
mxmxmx
mxmxmx wrote:
toneburst wrote:
I see. Well, hopefully the two modules will converge eventually.
I have an idea for an app for it, as it happens, if the same kind of application-switching setup as the O+C is implemented in the future.


that's the plan, there's the dev branch already which is based on the O+C code and is half-way there; it still lacks CV mapping. anyways, the same mode switching is/will be available, and since everything is combined in one app, there's plenty of space left for other apps.


fyi, CV is still mostly dysfunctional, but things are getting there:: https://github.com/mxmxmx/temps_utile-/tree/devdev_SEQ

the way this works atm is:

- "down" button toggles CV/parameter menu. click right encoder to enter edit mode (as with O+C); adjust parameter value or assign CV channel.
- "up" button toggles parameter menu/screensaver (or internal clock settings, if any -- this doesn't do anything yet)
- to clear all CV mappings long press the "down" button (when in CV menu).

- currently (basically) working is: CV over multiplication/division, pulsewidth, clock source (this just toggles TR1/TR2).
- in step sequencer mode: CV over sequence # (1-4).
- saving state: as with O+C, long press the right encoder (> app menu), long press again to save.
keninverse
Sweet. I'll get this flashed soon. CV over sequencing would be very useful. Is the internal clock still in the works?
Timmy
keninverse wrote:
Is the internal clock still in the works?


Hmmmm, an internal clock could be both voltage-controllable, and have its frequency/BPM shown on the display.
mxmxmx
keninverse wrote:
Sweet. I'll get this flashed soon. CV over sequencing would be very useful. Is the internal clock still in the works?


yep, the multiplication needs an internal timer anyways, so it shouldn't need a lot of additional work.

it's already there now in the UI: each channel has a parameter called "clock source", which can be set to "INT". that'll make a little indicator appear next to the channel #. alternatively, push the "up" button (displays a version of the screensaver), then long-press the "up" button, that'll make all six channels switch to internal clock; long-pressing the "down" button will clear all channels / reset them to external. as soon as at least one channel is set to "INT", a (global) BPM setting will become visible when pushing the "up" button. (that'll only affect those channels set to internal)
Timmy
mxmxmx wrote:
keninverse wrote:
Sweet. I'll get this flashed soon. CV over sequencing would be very useful. Is the internal clock still in the works?


yep, the multiplication needs an internal timer anyways, so it shouldn't need a lot of additional work.

it's already there now in the UI: each channel has a parameter called "clock source", which can be set to "INT". that'll make a little indicator appear next to the channel #. alternatively, push the "up" button (displays a version of the screensaver), then long-press the "up" button, that'll make all six channels switch to internal clock; long-pressing the "down" button will clear all channels / reset them to external. as soon as at least one channel is set to "INT", a (global) BPM setting will become visible when pushing the "up" button. (that'll only affect those channels set to internal)


Oooh, nice! I completely overlooked that feature!
Sinamsis
At the risk of sounding like a complete moron (I am) is there info out there on how to flash the new firmware? I looked through the github link and didn't see anything but I very well could've over looked it.
keninverse
Sinamsis wrote:
At the risk of sounding like a complete moron (I am) is there info out there on how to flash the new firmware? I looked through the github link and didn't see anything but I very well could've over looked it.



Follow the O+C method B firmware update method (https://github.com/mxmxmx/O_C/wiki/firmware) and just choose t_u_REV.ino when you're ready to compile. Just need to make sure you have the libraries installed and the associated files placed.
Altitude909
^
Power up module, plug in USB cable, start teensy loader, press reset button, on teensy, load hex in teensy loader, hit program in teensy loader, rejoice.
mxmxmx
keninverse wrote:
Sinamsis wrote:
At the risk of sounding like a complete moron (I am) is there info out there on how to flash the new firmware? I looked through the github link and didn't see anything but I very well could've over looked it.



Follow the O+C method B firmware update method (https://github.com/mxmxmx/O_C/wiki/firmware) and just choose t_u_REV.ino when you're ready to compile. Just need to make sure you have the libraries installed and the associated files placed.


yep, it should compile more or less as per O+C method B. there's no documentation yet, because the firmware has to be finished first....

btw, i've just pushed an update with the internal clock enabled, still needs some testing but superficially things seem to work ok:

here's the clock output, channel 6 at 100BPM (or 600ms), it defaults to quarter notes:

Sinamsis
You guys are awesome. Thanks so much.
mxmxmx
fwiw,

i've mostly completed the OC "port" now; the new firmware basically recreates the functionality that was there already (in one huge ugly "app"), except it adds:

- clock multiplication (2x, 3x, 4x, 5x, 6x, 7x, 8x)
- trigger sequencer mode / sequence editor
- improved UI
- more DAC modes (random, binary, "turing", logistic)
- more flexible CV mapping (CV sources can now be assigned to multiple destinations)
- trigger sources per channel (TR1, TR2, or internal timer)
- supports faster clocks (kHz rather than Hz)

chances are there's more than a few bugs in there still, so before i make this the default firmware, reports along these lines will be appreciated ... (quick guide)

https://github.com/mxmxmx/temps_utile-/tree/devdev_SEQ
Sinamsis
Any chance of being able to assign PPQN in future updates? I have a sequencer that expects 24 PPQN. Would love to be able to drive it with this bad boy.
Sinamsis
Oh and one more question as I'm starting to use this... Previously I believe the TR2 input was a reset input. What is it now? Before I updated the firmware I was using Yarns to send clock and a start signal for reset, and I believe it was working fine (or I didn't notice). Now, sending the same start signal to TR2 input seems to make it skip a beat. I suspect I'm doing something wrong.

Ha, but while we're throwing feature requests out there (we are, aren't we? oops ), would it be possible to define what sort of reset we're using? Like a start signal, start/stop signal, run on high gate sort of thing?
nevetsokyeron
I spent some time earlier finding Mouser part numbers for most of the stuff in the BOM.

Maybe this will be useful for others. If anyone has replacement part suggestions, please let me know.

603-RC0805FR-07100RL 100R 0805
603-RC0805JR-07510RL 510R 0805
667-ERA-6AED102V 1k 0805
667-ERA-6AED122V 1.2k 0805
754-RG2012P-182DT5 1.8k 0805
667-ERA-6AED302V 3k 0805
667-ERA-6AED392V 3.9k 0805
667-ERA-6AED682V 6.8k 0805
660-RK73H2ATTD1002F 10k 0805
756-PCF0805R-24K9BT1 20k 0805
660-RK73H2ATTD3302F 33k 0805
660-RK73H2ATTD1003F 100k 0805

81-GRM40C102J50D 1nF Ceramic Capacitor 0805
81-GRM215C1H332JA01D 3.3nF Ceramic Capacitor 0805
81-GRM21B5C1H183JA1L 18nF Ceramic Capacitor 0805
80-C0805C104K5R 100nF ceramic Capacitor 0805
77-VJ0805Y474JXJTBC 470nF ceramic Capacitor 0805
581-08055C105K4Z2A 1uF ceramic Capacitor 0805
81-GRM21BR6YA106KE3L 10uF ceramic (or tantal) Capacitor 0805
81-GRM39X103K50D 10nF Ceramic Capacitor 0603

595-TL074CDR TL074 (SOIC-14)
579-MCP6004T-I/SL MCP6004 (SOIC-14)
512-MMBT3904 MMBT3904 (NPN) (SOT-23)
621-1N5817 1N5817 (diode) (DO-41)
511-LD1117S50 LM1117-50 (SOT-223)
926-LM4040DIM350NOPB LM4040 5v0 (SOT-23)
81-LQH31MN100J03L Fixed inductor, 10uH (1206)

647-UPM1V220MDD1TD 22uF cap - RM2.5 (35V or better)
581-TAP474K035CCS 470nf 5mm - film/ceramic , 35v / 0.47uF
511-L78L33ACZ TO-92 3.3v regulator
517-929870-01-08-RA 1x7 (1x8) OLED socket - 2.54mm, **low profile** !
642-5GTH935 Tact switches - multimecs 5E/5G
642-1SS09-15.0 Switch caps - multimecs 1SS09-15.0 or -16.0

PEC11R-4215K-S0024 encoders - 24 steps w/ switch
649-67996-410HLF 2x5 pin header - 2.54mm (euro power connector)
571-15342372 1x14 socket - 2.54mm, socket for teensy 3.x

EDIT -- Updated 100R because previous one changed to a 5000 min order.
Timmy
nevetsokyeron wrote:
I spent some time earlier finding Mouser part numbers for most of the stuff in the BOM.

Maybe this will be useful for others. If anyone has replacement part suggestions, please let me know.

279-1623096-1 100R 0805
603-RC0805JR-07510RL 510R 0805
667-ERA-6AED102V 1k 0805
667-ERA-6AED122V 1.2k 0805
754-RG2012P-182DT5 1.8k 0805
667-ERA-6AED302V 3k 0805
667-ERA-6AED392V 3.9k 0805
667-ERA-6AED682V 6.8k 0805
660-RK73H2ATTD1002F 10k 0805
756-PCF0805R-24K9BT1 20k 0805
660-RK73H2ATTD3302F 33k 0805
660-RK73H2ATTD1003F 100k 0805

81-GRM40C102J50D 1nF Ceramic Capacitor 0805
81-GRM215C1H332JA01D 3.3nF Ceramic Capacitor 0805
81-GRM21B5C1H183JA1L 18nF Ceramic Capacitor 0805
80-C0805C104K5R 100nF ceramic Capacitor 0805
77-VJ0805Y474JXJTBC 470nF ceramic Capacitor 0805
581-08055C105K4Z2A 1uF ceramic Capacitor 0805
81-GRM21BR6YA106KE3L 10uF ceramic (or tantal) Capacitor 0805
81-GRM39X103K50D 10nF Ceramic Capacitor 0603

595-TL074CDR TL074 (SOIC-14)
579-MCP6004T-I/SL MCP6004 (SOIC-14)
512-MMBT3904 MMBT3904 (NPN) (SOT-23)
621-1N5817 1N5817 (diode) (DO-41)
511-LD1117S50 LM1117-50 (SOT-223)
926-LM4040DIM350NOPB LM4040 5v0 (SOT-23)
81-LQH31MN100J03L Fixed inductor, 10uH (1206)

647-UPM1V220MDD1TD 22uF cap - RM2.5 (35V or better)
581-TAP474K035CCS 470nf 5mm - film/ceramic , 35v / 0.47uF
511-L78L33ACZ TO-92 3.3v regulator
517-929870-01-08-RA 1x7 (1x8) OLED socket - 2.54mm, **low profile** !
642-5GTH935 Tact switches - multimecs 5E/5G
642-1SS09-15.0 Switch caps - multimecs 1SS09-15.0 or -16.0

PEC11R-4215K-S0024 encoders - 24 steps w/ switch
649-67996-410HLF 2x5 pin header - 2.54mm (euro power connector)
571-15342372 1x14 socket - 2.54mm, socket for teensy 3.x


The majority of the parts are the same as in O&C. Just use the Mouser part numbers from the O&C BOM and you won't go wrong. Then you only need to find Mouser part numbers for the parts that differ from O&C.
mxmxmx
Sinamsis wrote:
Any chance of being able to assign PPQN in future updates? I have a sequencer that expects 24 PPQN.


i don't have any equipment to test this with, i think, but sure, i can try; it's basically just like multiplication, if i see this right. the resolution is 60 microseconds so that should work reasonably well with the internal timer; it'll probably be a bit jittery when deriving it from an external clock, ... but then what isn't.

Sinamsis wrote:
Oh and one more question as I'm starting to use this... Previously I believe the TR2 input was a reset input. What is it now? Before I updated the firmware I was using Yarns to send clock and a start signal for reset, and I believe it was working fine (or I didn't notice). Now, sending the same start signal to TR2 input seems to make it skip a beat. I suspect I'm doing something wrong.


it shouldn't reset or make skip anything except when explicitly set to "reset". there's actually just two modes with "reset" options: euclidian and the trigger sequencer, in which case, if enabled, "reset" resets a/the counter. it'll probably need some fine-tuning though, atm, it'll reset said counter as long as the input is high, so you'll probably want to try with a trigger rather than a gate signal. the main difference to the old firmware is that TR2 can be selected as an alternative clock source now, so you could have, say, channels #1-4 track TR1, and channels #5-6 track TR2 or any combination thereof. you can also toggle the source, by assigning a CV input to "clock source". this will switch from TR1 to TR2 if the input goes high (> 1.2V), or v.v. if TR2 is selected as the channel clock source.


Sinamsis wrote:

Ha, but while we're throwing feature requests out there (we are, aren't we? :oops: ), would it be possible to define what sort of reset we're using? Like a start signal, start/stop signal, run on high gate sort of thing?


mmh, don't know about start/stop but how about: "do nothing when input goes high", and "only do something when input goes high"; those would be easy.


nevetsokyeron wrote:
I spent some time earlier finding Mouser part numbers for most of the stuff in the BOM.


cool, i'll update the one on github when i get around; pull requests for this kind of stuff are always welcome of course
m0d
mxmxmx wrote:

i've mostly completed the OC "port" now;


I have ordered an OC from Raph but I also need something for clock duties. I've been trying to absorb all the info from different threads before asking. Is the temps_utile going to continue to grow and/or is o+c going to have a lot of this functionality?

I'm considering a t_u, especially for the six outputs. I'm open to getting a second ornament+crime though if that is the path moving forward.

I'm also excited about what you (and others) might do with the Teensy 3.6. smile
mxmxmx
mxmxmx wrote:



Sinamsis wrote:

Ha, but while we're throwing feature requests out there (we are, aren't we? :oops: ), would it be possible to define what sort of reset we're using? Like a start signal, start/stop signal, run on high gate sort of thing?


mmh, don't know about start/stop but how about: "do nothing when input goes high", and "only do something when input goes high"; those would be easy.


fwiw, not quite start/stop but i've added some "freeze" parameter with the latest commit, as it seems useful; basically, it pauses the channel if TR2 goes high or low, ie depending on settings. quick test: channels 1 (sequencer mode, 2x) and 2 (random, 4x) active when TR high (freeze "= LO"), going into peaks; channel 4 (in DAC / LFSR mode, 2x) when low (freeze "= HI"), and going into some oscillator etc. the sequence # and random threshold parameters are modulated somewhat, too --

[s]https://soundcloud.com/menschenimhotel/pause/s-ewwvC[/s]


m0d wrote:
mxmxmx wrote:

i've mostly completed the OC "port" now;


I have ordered an OC from Raph but I also need something for clock duties. I've been trying to absorb all the info from different threads before asking. Is the temps_utile going to continue to grow and/or is o+c going to have a lot of this functionality?

I'm considering a t_u, especially for the six outputs. I'm open to getting a second ornament+crime though if that is the path moving forward.


i don't have plans re TU except finishing up this refurbishment; i use them side-by-side quite a bit, so i mainly wanted to homogenize the UI concepts. the other reason is that i don't have a lot of ideas re continuing to grow this, it already covers most of the more obvious clock processing functionalities, albeit in a single app. it's simple enough, but a much more powerful source-of-clocks than OC, which only covers some of the basics in the envelope mode. as far as OC is concerned, there won't be much growth in that direction either, .... considering you don't really need a 15$ DAC for outputting a bunch of pulses.
Sinamsis
mxmxmx thanks so much for the in depth response. It's fantastic that you're even considerin feedback like this. Re PPQN, yes I assume multiplying the clock x24 takes a regular clock and makes it 24 PPQN. Sounds like TU definitely has this resolution. About jitter, at 24 PPQN since the values are averaged as far as I understand it a little jitter between pulses shouldn't have much effect compared to a clock that's expecting one pulse for every quarter note.

About reset on clocks. I noticed after I posted the other modes do have resets. The only reason I'd want a reset is to keep relationships in phase as you're modulating the hell out of the clocks. So let's say kick and snare stay in the same position relative to each other if they're both driven by TU.

Another thought would be to be able to specify and or modulated the phase of the clocks. Again not a deal breaker for me. And judging by everything Make Noise went through to get Tempi up and running, I suspect some of this stuff is very difficult.

To me TU has most of the features I wanted from a clock multiplier/divider, and way more than I could have expected. Pams was nice, but only one mod input. Plus you needed a whole different firmware to do Euclidean stuff. Tempi, same thing about modulation. And the firmware was still buggy when I had it. QCD with the expanded is great. But huge in terms of hp to function. And WAY more limited. TU will probably find a place in my bigger case as well (maybe even a couple haha). I already have one in my smaller case and I'm loving it so far. So anyways I'm just saying I appreciate all the hard work that's gone into this. And I love what you've done already. Just some additional thoughts here. Haha.

Oh and is there somewhere to donate? Not sure if I missed this.
nevetsokyeron
Timmy wrote:

The majority of the parts are the same as in O&C. Just use the Mouser part numbers from the O&C BOM and you won't go wrong. Then you only need to find Mouser part numbers for the parts that differ from O&C.


Yup - that's exactly what I did.
mxmxmx
Sinamsis wrote:


About reset on clocks. I noticed after I posted the other modes do have resets. The only reason I'd want a reset is to keep relationships in phase as you're modulating the hell out of the clocks. So let's say kick and snare stay in the same position relative to each other if they're both driven by TU.


here is a version doing "reset" for the divisions, too, so that's available for all modes. i doesn't do anything about multiplication yet. anyways, as i'm never quite sure about how reset inputs are supposed to behave, does this look about right?



yellow is /3, blue is /5, pink is a/the (random/out of phase) reset signal. when it goes high, the outputs go high on the next clock.


Quote:

Another thought would be to be able to specify and or modulated the phase of the clocks.


that's sort of possible in sequencer mode, you can rotate the pattern manually or with CV, but it's not easy to get predictable results i suppose.

Quote:

Oh and is there somewhere to donate? Not sure if I missed this.


no.
Sinamsis
mxmxmx
I have to think about it. The way I'm understanding this would be as follows.

Lets say you have a 4 bar loop, you get a pulse on the 4 of the last bar, and things would be synced on the 1 of the first bar as the loop repeats. So I guess that would work. Not sure how useful it would be. Unless, instead of a random reset like in the example, you're using lets say a clock divided significantly like /32 or /64 and if received in sync with a clock that will be beat 1 of the first bar.

I hope I'm explaining this well.

The other reason this is important is most dividers/multipliers take at least a beat or two to average the incoming clock before putting out a steady clock. Tempi initially in my set up did this very poorly, and at times would go completely out of phase right from the start, which made it unusable for me. I haven't had enough time with TU to know how it responds; it seems more stable than Tempi was. But, my point is lets say you have a bunch of other sequencers running, and you have modulated clocks as additional "gate sequencers" of sorts, if you don't have a reset, shit goes bonkers fast. The patterns you've created with the modulated clocks are totally out of phase with your other sequences. For me my master clock as always coming from a DAW, and there are usually many moving parts so I want things locked in as tightly as I can get them. Resets play an important part in that.

As an aside, I'm not sure why clock dividers need a beat or two to "catch up." If code could be written to start off at a division of the previously calculated clock, and then drift if need be to the correct tempo. I understand that for clock multiplication you need several beats. I just don't get why you need it for divisions.

And now that I think about it, the start stop type of signal doesn't make sense for the TU since it doesn't produce clocks until an incoming clock is sensed.

Again, maybe I'm expecting too much out of the clock division/multiplication features since there's probably other ways of doing what I'm looking for, like using the sequencer. Just shooting some ideas around.
thelizard
Finished my TU build last week, but only got to spend an hour with it tonight. Absolutely incredible work! A few of my larger, less versatile clock modules are looking nervous... Also, just ordered parts for a second O+C. Can't wait to bounce them off of each other.

Two quick implementation questions regarding both modules:
1) I know that you can save the module and app states using a right long-press on the app selection screen. Is there a way to reset everything to defaults? Perhaps a left long-press?

2) Could there be a way to directly attenuate CV signals from the assignment screens? Right now, each module really needs a 4-channel attenuator next door.
mxmxmx
thelizard wrote:
Finished my TU build last week, but only got to spend an hour with it tonight. Absolutely incredible work! A few of my larger, less versatile clock modules are looking nervous... Also, just ordered parts for a second O+C. Can't wait to bounce them off of each other.


cool, thanks for trying...

re :
thelizard wrote:

Two quick implementation questions regarding both modules:
1) I know that you can save the module and app states using a right long-press on the app selection screen. Is there a way to reset everything to defaults? Perhaps a left long-press?


easy in TU, as left long-press wasn't doing anything yet: added here. right now, that'll reset things to the last saved settings and clear all CV mappings. the alternative behaviour would be to reset all channels to basic mult/div mode. not sure off my head how best to handle this with OC, as long-pressing the encoder already resets some apps to defaults, or just clears certain stuff in others. probably it could be done from within the app selection menu

thelizard wrote:

2) Could there be a way to directly attenuate CV signals from the assignment screens? Right now, each module really needs a 4-channel attenuator next door.


in theory yes, but i think we'd like to avoid adding too many options/menu pages. it's true, you basically need a 4x attenuator or offset/attenuator thingie to get much use out of the CVs; on the upside, that makes it somewhat more playable...


Sinamsis wrote:

Lets say you have a 4 bar loop, you get a pulse on the 4 of the last bar, and things would be synced on the 1 of the first bar as the loop repeats. So I guess that would work. Not sure how useful it would be. Unless, instead of a random reset like in the example, you're using lets say a clock divided significantly like /32 or /64 and if received in sync with a clock that will be beat 1 of the first bar.


i think that should work with the present scheme *if* your reset clock is absolutely in phase. if it lags behind by more than a few microseconds, it won't take effect until the next incoming clock; i'll have to experiment a bit more but i suppose i might end up adding a configurable latency as with the quantizer in OC. clicking the left encoder should have a similar effect, ie re-syncing the various counters etc across channels.

Sinamsis wrote:

The other reason this is important is most dividers/multipliers take at least a beat or two to average the incoming clock before putting out a steady clock.


this doesn't average, it just echos whatever comes in; for multiplication, it'll need at least two clocks of course, so that it can know what the incoming clock frequency is.
pld
thelizard wrote:
Two quick implementation questions regarding both modules:
1) I know that you can save the module and app states using a right long-press on the app selection screen. Is there a way to reset everything to defaults? Perhaps a left long-press?

For O+C you can hold the Up + Down buttons in the boot screen to reset all the app/global settings (but in theory, not the calibration). As mxmxmx says something could probably be added for individual apps in the selection menu.
thelizard
pld wrote:
thelizard wrote:
Two quick implementation questions regarding both modules:
1) I know that you can save the module and app states using a right long-press on the app selection screen. Is there a way to reset everything to defaults? Perhaps a left long-press?

For O+C you can hold the Up + Down buttons in the boot screen to reset all the app/global settings (but in theory, not the calibration). As mxmxmx says something could probably be added for individual apps in the selection menu.


Thanks! I had an interface design idea to clean this up.

When holding the right encoder to load the app menu, instead of simply listing the apps, there could be two tabs: "Apps" and "Global". Turning the left encoder will switch between the tabs.

"Global" could have:
-Save module state
-Reset to last saved state
-Reset to defaults
-Randomize app settings (Maybe? Unsure if this would be useful)
-Re-calibrate
-Encoder direction (or a general options page, instead of some of the invisible settings that are currently present.)

With that, the app-load screen would have a similar interface to any of the multi-channel apps.

Random (possibly terrible) idea: The Global tab could have a CV Attenuation page that sets global attenuation for the 4 CV inputs. That way, the CV settings don't complicate the individual app settings pages. It would provide a more "set-and-forget" type attenuation instead of the more interactive method that an external attenuator would provide.

Another random CV idea: Perhaps when you are on the CV assignment page, selecting an attenuation source (clicking the right encoder and then turning it) could bring up a sort of dual interface widget. Turning the right encoder could pick the CV source, and turning the left encoder (while the element is active) could set the depth (i.e. it could switch between displaying "CV2" and "88%" depending on which knob was turned last).

The main issue with this is that it would add a whole pile of variables to memory, instead of the four that the global options page would provide. Its main benefit is that you could route one CV input to multiple destinations with per-destination depth.
mxmxmx
thelizard wrote:

Random (possibly terrible) idea: The Global tab could have a CV Attenuation page that sets global attenuation for the 4 CV inputs. That way, the CV settings don't complicate the individual app settings pages. It would provide a more "set-and-forget" type attenuation instead of the more interactive method that an external attenuator would provide.

Another random CV idea: Perhaps when you are on the CV assignment page, selecting an attenuation source (clicking the right encoder and then turning it) could bring up a sort of dual interface widget. Turning the right encoder could pick the CV source, and turning the left encoder (while the element is active) could set the depth (i.e. it could switch between displaying "CV2" and "88%" depending on which knob was turned last).


i'll think about it. something along the lines of random idea #2 sounds feasible, using the left encoder to set the modulation amount.

also fwiw, early adopters (= if you have a yellow PCB) still need to comment out the switch (#define _TEMPS_UTILE_REV) to make things compile correctly. (because pin usage is slightly different vs. the later versions of the PCB ("rev1")). the procedure is described in the (semi-updated) wiki: https://github.com/mxmxmx/temps_utile-/wiki/firmware

added/tweaked a few small things over the weekend. mainly there's a few more pulse-width settings, "echo" (incoming pulse-width) and 50% duty cycle, which will put out gates rather than just triggers. (to "echo", turn the PW setting to 0, "50%" is at 255). don't know whether that's useful, but it adds some variation, e.g. when tracking pulse-width in the logic modes or the 'binary' sequencer:



pink is the external clock, blue just echos the input, yellow is the binary/5-bit sequencer at 2x.

and this is "50%" (blue in the middle, which is set to /2):



yellow is set to x2, with the pulse-width modulated by some LFO.
thelizard
I have some free time, so I'd really like to help cleanup and expand this project!

I've forked the repo and started work on my first basic app, which is a sequential trigger/gate source (like a Doepfer A-161, or the gating row on the Metropolis).

So far, I haven't run into any issues, but I want to make sure of a few things:

1) Are Max, Patrick, and/or Tim working on something similar that I could contribute to instead of starting the app from scratch?

2) It seems prudent to create a generalized "Gate" class that can be re-used throughout Apps. Right now, in the 6xClocks app, all of the gate width and mult/div logic is contained inside of the Clock_channel class, which also contains a lot of options and variables unique to this specific implementation. Would you be against breaking out that logic to a Gate class and making Clock_channel inherit from it?

3) Are you against sending in optimization pull requests for 6xClocks? For instance:
https://github.com/mxmxmx/temps_utile-/blob/devdev_SEQ_RESET/soft/t_u_ REV/APP_CLK.ino#L582
Could be cleaned up by returning _ZERO if channel == 4, and returning 0 otherwise. The "_off" variable is redundant in this situation.

4) I haven't worked much on large Arduino/Teensy projects before, and am just getting a feel for scope and compilation. Are the consts declared at the top of APP_CLK (https://github.com/mxmxmx/temps_utile-/blob/devdev_SEQ_RESET/soft/t_u _REV/APP_CLK.ino#L44) visible to other apps? Should they be refactored into a different, app-specific scope if so?

EDIT: I now see that all of those consts are global to .ino files.
I'm thinking that logic functions/handling and multiplication/division tables should be refactored in a manner similar to TU_BPM.h, since those will be common to many clock/trigger/gate apps.

EDIT 2: I've started editing APP_CLK here: https://github.com/mhetrick/temps_utile-/commit/0106e95c532ddc5b901849 5233bdc27a98eb45d7
So far, I've only really taken out consts related to mult calculation. I also broke the processing stage up into various modes.
dusk
mxmxmx

which of your modules would be good for a second time surface mount solderer? I eventually want to get through all the modules you made, but which one is the easiest to start with?
mxmxmx
thelizard wrote:
I have some free time, so I'd really like to help cleanup and expand this project!


sure, please do!

thelizard wrote:

1) Are Max, Patrick, and/or Tim working on something similar that I could contribute to instead of starting the app from scratch?


no, i don't think. just fyi, but you've probably seen that: i've temporarily commented out the right encoder events in the app selection menu, it would crash when turning it; this of course will have to go in again when adding apps; and should make the crashing go away, too.

thelizard wrote:

2) It seems prudent to create a generalized "Gate" class that can be re-used throughout Apps. Right now, in the 6xClocks app, all of the gate width and mult/div logic is contained inside of the Clock_channel class, which also contains a lot of options and variables unique to this specific implementation. Would you be against breaking out that logic to a Gate class and making Clock_channel inherit from it?


... true, that might be a helpful thing to have. a lot of it boils down to just counting ticks, but it would make things look cleaner overall. the div/multiplication code turned out to be a fairly empirical affair, not really based on some superior logic; but yeah, all the other clock modes just operate on that, and it seems to works alright. anyways, there's not much in the way of rules as far as i am concerned.

thelizard wrote:

3) Are you against sending in optimization pull requests for 6xClocks?


of course not. i've made an effort using the funny ARM instruction set for multiplications throughout, so the code shouldn't be particularly inefficient, generally speaking, but i was mainly looking to get things into usable shape and the code definitely could use some pruning.

that said, there's probably not much to be won by optimizing on that level. the latency as is is < 100 us, as with O+C, as it's running Patrick's core engine unchanged. in theory, because there's no SPI DAC but just the OLED and a few GPIO, the update could be disentangled from the SPI/DMA stuff though; the resolution (which is limited by the OLED, mainly) might then be increased, but 60us seems to be good enough; it would be nice for the DAC though.

thelizard wrote:

EDIT: I now see that all of those consts are global to .ino files.
I'm thinking that logic functions/handling and multiplication/division tables should be refactored in a manner similar to TU_BPM.h, since those will be common to many clock/trigger/gate apps.


yep. i can't say that i see through the arduino precompiler, but these would be seen only within that "ino" file. otherwise, extern const, as with TU_BPM.h, or à la TU_strings.cpp.

thelizard wrote:

EDIT 2: I've started editing APP_CLK here: https://github.com/mhetrick/temps_utile-/commit/0106e95c532ddc5b901849 5233bdc27a98eb45d7
So far, I've only really taken out consts related to mult calculation. I also broke the processing stage up into various modes.


cool, curious what you'll come up with.

dusk wrote:
mxmxmx

which of your modules would be good for a second time surface mount solderer? I eventually want to get through all the modules you made, but which one is the easiest to start with?


@dusk: this one. it's just SOIC and 0805, and no expensive parts involved. so yes, i suppose it's good to practice.
justin3am
I have two of each (O+C and TU) PCB on their way and I just ordered parts and panels for them. I can't wait to start building!

I'm still very new to programming but I have had some good luck experimenting with Arduinos recently, so I'm excited to start exploring a platform which has the hardware already setup for the kinds of things I want to do.

thelizard wrote:
I have some free time, so I'd really like to help cleanup and expand this project!


Hey Michael! Not busy enough already, eh?
thelizard
justin3am wrote:
I have two of each (O+C and TU) PCB on their way and I just ordered parts and panels for them. I can't wait to start building!

I'm still very new to programming but I have had some good luck experimenting with Arduinos recently, so I'm excited to start exploring a platform which has the hardware already setup for the kinds of things I want to do.

thelizard wrote:
I have some free time, so I'd really like to help cleanup and expand this project!


Hey Michael! Not busy enough already, eh?


Never!!! We sent off our alpha for the last Unfiltered plug-in of the year. It should be out in October. At this point, I'm just working on finishing up my dissertation and fixing bugs as the QA team sends reports. I just need a "fun" project to have in the background since the others are excruciating.

You're gonna love these modules. I have a 2nd O+C PCB on the way, and I'm already considering a second TU as a hack away at this. If you haven't taken a look at it, you should consider building a Dervish as well: https://www.muffwiggler.com/forum/viewtopic.php?t=160436

Right now, O+C, TU, and Dervish are essentially the DIY Trinity in my book. CV, timing, and multi-FX, all in compact packages with great OLED screens.
justin3am
thelizard wrote:
Right now, O+C, TU, and Dervish are essentially the DIY Trinity in my book. CV, timing, and multi-FX, all in compact packages with great OLED screens.


There are so many cool projects available right now, it's not even funny. I've been following the Dervish but I built a DIY Clouds earlier in the year (among a bunch of other things) but I like the idea of being able to hack the firmware. I had a Z-DSP but never got the programmer for it.

Two things I'm curious about...
Is it possible to offset divided clocks? Say I have a have a clock that is divided by two and I want to offset it by one clock, so that output would go high on the 2 and the 4, rather than the 1 and the 3. Of if a have a clock that is divided by 4, and I want to offset it by 3 so the output goes high on the 4 and the 8. It looks like I can do that with 'Rotate' in the sequencer mode, is that right? Is that parameter available for modulation?

Also, the Rotating Clock Divider has an option to switch between up-beat and down-beat counting. I'm no good at describing these things... this is what the manual says:
Quote:
In Up-beat counting, each jack fires after "N" number of pulses are counted on the input jack (where N is the divide-by-number). So, after a Reset pulse, only the /1 jack will fire after a Reset on the first clock pulse. On the next clock pulse, the /1 and the /2 jack will fire, then on the next pulse the /1 and /3 jacks will fire, etc...
In Down-counting, each jack fires when its count is 1. So all the jacks will fire after a Reset pulse, and then count up to "N", and fire again when they start over at 1. This is called "down-beat counting" because all the jacks fire on the down-beat (first clock pulse).

Is there a way to accomplish something similar with the TU?
mxmxmx
justin3am wrote:

Two things I'm curious about...
Is it possible to offset divided clocks? Say I have a have a clock that is divided by two and I want to offset it by one clock, so that output would go high on the 2 and the 4, rather than the 1 and the 3. Of if a have a clock that is divided by 4, and I want to offset it by 3 so the output goes high on the 4 and the 8. It looks like I can do that with 'Rotate' in the sequencer mode, is that right? Is that parameter available for modulation?


right now, that can only happen by accident; ie because the dividers default to 'free-running' rather than deriving from the same counter. you can sync the channels manually by pushing the left encoder or by setting the "reset/mute" setting to "RST2" (or "RST1", depending on the channel clock source). it'll be easy to add an offset though.

the euclidian and sequencer modes can be offset resp. rotated already, and both parameters are available for modulation; basically any parameter is, except "reset/mute" and "track-->" (which is available in the logic and binary sequencer modes. see here for details). so in theory you can cycle through the 4 sequence patterns, giving you up to 64 length, but that'll still need some fine tuning in terms of the UI; and there probably should be an option to advance by trigger. as things are, only the 'active' pattern can be edited (= the one selected by "sequence #"), which is a little confusing/annoying when modulating "sequence #".


justin3am wrote:

Also, the Rotating Clock Divider has an option to switch between up-beat and down-beat counting. I'm no good at describing these things... this is what the manual says [...]


it should be down-beat, see the scope shot on top of this page. the way "reset" is implemented doesn't yet correspond to either mode though, i think. might have to fix that.

justin3am wrote:

Is there a way to accomplish something similar with the TU?


you mean as in switching between mathematical and musical division? no, not right now; but conceivably it could be added as an option. the consensus seems to be "musical" division is preferable, but considering things can get out of hand pretty quickly anyways (6 channels, 6 modes, lots of pseudorandomness, CV) ... why not divide mathematically.
justin3am
Thanks for the detailed answers. That makes sense.

I assumed that it worked from the down-beat based on your scope shots, I was just interested to know if it was possible to change that behavior. I think "musical" divisions are more useful but I found that there are some cases when it's nice to have mathematical divisions.

Anyway, I feel a bit silly getting too deep into a discussion about features before I've even built the modules. hihi
thelizard
justin3am wrote:
Thanks for the detailed answers. That makes sense.

I assumed that it worked from the down-beat based on your scope shots, I was just interested to know if it was possible to change that behavior. I think "musical" divisions are more useful but I found that there are some cases when it's nice to have mathematical divisions.

Anyway, I feel a bit silly getting too deep into a discussion about features before I've even built the modules. hihi


It's worth mentioning that the RCD is open-source and written for AVR (same platform as Arduino), making it very easy to port:
https://github.com/4ms/RCD/blob/master/clocker.c

Which makes me think... The sequential gate sequencer app that I'm working on is single-counter based, much like the RCD. It might be worth designing this app to cover some of the single-counter paradigms that the 6xClocks mode can't do as well.

Alternatively... It may be worth re-writing portions of the 6xClocks mode so that each clock can be set to SEQ mode and provide methods for observing a central counter in addition to the independent counting that currently happens.
mxmxmx
thelizard wrote:


It's worth mentioning that the RCD is open-source and written for AVR (same platform as Arduino), making it very easy to port:
https://github.com/4ms/RCD/blob/master/clocker.c

Which makes me think... The sequential gate sequencer app that I'm working on is single-counter based, much like the RCD. It might be worth designing this app to cover some of the single-counter paradigms that the 6xClocks mode can't do as well.


true, shouldn't be too difficult; and would make it easier to dial in some of the more basic clock things.

i've only looked superficially, but i don't see how it offers a solution to the drift/sync thing though; there's 8 counters in the RCD code, the main difference, as far as i can tell, is that there's no individual control over the division factors; there's just "spread", which affects all the channels, so the channels never diverge. in TU, the divisors can change at any time, per channel, so things diverge very easily because the effect is instant/on the next clock. the update behaviour could be changed, i suppose, but that'll mean less immediacy. no?

i wonder how the QCD does this, if it does this; it's four attiny85s, IIRC.
thelizard
Here are a few proposals for apps and upgrades that I want to work on:

Apps (with O+C style pun groaners):

Trois Pair: Three clock pairs. The basis for the mode is Mutable's Branches (probability switching between two outputs), but I imagine that a lot more can be done with this.

Seq-seis: Sequencer with six steps. Counting modes could be forwards, backwards, ping-pong, random, etc. Clock could be strobed, triggered, or burst generated. Perhaps individual steps could have multiplied outputs? This could behave similarly to the original Stillson Hammer (http://www.theharvestman.org/1974.php). Could also emulate something like the Turing Machine's Pulses expander in that a single LFSR could be used to sequentially address the six outputs (instead of how the LFSR mode is currently on a per-Clock channel basis).

Even Sieven: All six clocks observe an integer counter (master clock). Trig 1 advances the counter, Trig 2 resets the integer to 0. This mode could easily emulate the RCD. Xenakis Sieves could be implemented easily as well (hence the stupid name). Also allows binary counting outputs, primes, Fibonacci, etc.

Feature Improvements for 6xClocks/All Modes:
-Add all outputs as input trigger sources for individual clocks. For instance, Clock 2 could be triggered by the output of Clock 1 (instead of Trig input 1/2/Int). One of my favorite QCD tricks is to cascade the clocks into each other. Changing the clock at the top of the chain has dramatic effects on the rest.
-Add all outputs as modulation sources. For instance, Clock 2's Mult can be targeted by the output of Clock 1 (instead of, say, CV 1).
-Break out the multiplier logic into its own class so that it's more easily re-usable between apps.
-Break out logic operations (AND, OR, etc.) into a static class. Allow three-operator logical operations (maybe more?). Maybe add C-Gate, although that would require history.
-DAC Mix mode: Mixes the outputs of Clocks 1, 2, 3, 5, and 6 with bipolar levels. Allows you to create weird sequences from existing clock outputs.
-I'm toying with the idea of clock jitter as well. One of my favorite SuperCollider uGens for microsound is a clock with Gaussian disturbances. It stays fairly close to the main tempo, but provides a very pleasant amount of organic failure.

I got the bare skeleton for Seq-seis compiling today, so things are coming along!
justin3am
So many good ideas in there! I particularly like the idea using the output of one clock for the input of another.
Such a neat project!
nevetsokyeron
Has anyone in the US already had some Temps PCBs made?

If not I may get some made or just order a couple from mxmxmx
thelizard
nevetsokyeron wrote:
Has anyone in the US already had some Temps PCBs made?

If not I may get some made or just order a couple from mxmxmx


Nope, not yet. However, Modular Addict has TU and O+C Panels in stock:
http://modularaddict.com/oscillosaurus-tempsutile-panel

Magpie recently started stocking O+C panels and PCBs, so maybe they'll carry TU soon? http://magpie-modular.myshopify.com/collections/murdered-out-modules/p roducts/pre-order-ornament-crime-panels-pcbs
Timmy
thelizard wrote:
Here are a few proposals for apps and upgrades that I want to work on:

Apps (with O+C style pun groaners):


Punning app names are de rigeur. Given the French name of the module, Oulipo-style jeux de mots get extra points...

thelizard wrote:
Trois Pair: Three clock pairs. The basis for the mode is Mutable's Branches (probability switching between two outputs), but I imagine that a lot more can be done with this.


Definitely. The obvious extension to Branches would be non-uniform probability density functions (probability distributions). Maybe start with a Gaussian (normal) distribution, with settable mu (mean) and sigma-squared (variance), but there re many others which could be useful.

thelizard wrote:
Seq-seis: Sequencer with six steps. Counting modes could be forwards, backwards, ping-pong, random, etc. Clock could be strobed, triggered, or burst generated. Perhaps individual steps could have multiplied outputs? This could behave similarly to the original Stillson Hammer (http://www.theharvestman.org/1974.php). Could also emulate something like the Turing Machine's Pulses expander in that a single LFSR could be used to sequentially address the six outputs (instead of how the LFSR mode is currently on a per-Clock channel basis).


So that would output a CV on channel 4 (D), and maybe triggers gates on the other channels? Why six steps?

thelizard wrote:
Even Sieven: All six clocks observe an integer counter (master clock). Trig 1 advances the counter, Trig 2 resets the integer to 0. This mode could easily emulate the RCD. Xenakis Sieves could be implemented easily as well (hence the stupid name). Also allows binary counting outputs, primes, Fibonacci, etc.


Definitely. Fibonacci series will be added as a value source on O+C too at some stage - an array of pre-computed fibonacci series is already stashed away in the a code table in preparation for that.


thelizard wrote:
Feature Improvements for 6xClocks/All Modes:
-Add all outputs as input trigger sources for individual clocks. For instance, Clock 2 could be triggered by the output of Clock 1 (instead of Trig input 1/2/Int). One of my favorite QCD tricks is to cascade the clocks into each other. Changing the clock at the top of the chain has dramatic effects on the rest.
-Add all outputs as modulation sources. For instance, Clock 2's Mult can be targeted by the output of Clock 1 (instead of, say, CV 1).
-Break out the multiplier logic into its own class so that it's more easily re-usable between apps.
-Break out logic operations (AND, OR, etc.) into a static class. Allow three-operator logical operations (maybe more?). Maybe add C-Gate, although that would require history.
-DAC Mix mode: Mixes the outputs of Clocks 1, 2, 3, 5, and 6 with bipolar levels. Allows you to create weird sequences from existing clock outputs.


All those sound great. Internal patching of outputs to inputs via a mod-matrix makes sense.

Going beyond hard logic to fuzzy logics might also be possible. In other words, implementing neural nets. A number of NN topologies could be implemented, with various activation and transfer functions. Has anyone implemented a neural network rhythm source yet? It could be the first. I would suggest prototyping on a PC in an existing NN framework (there are many) to make sure it is useful and musical in some fashion.

thelizard wrote:

-I'm toying with the idea of clock jitter as well. One of my favorite SuperCollider uGens for microsound is a clock with Gaussian disturbances. It stays fairly close to the main tempo, but provides a very pleasant amount of organic failure.


Even better if the mean and the variance of the Gaussian jitter are voltage-controllable, so that timing can be modulated from tight to sloppy in various ways. Maybe add a skewness parameter too (see Branches discussion above) so that the proportion of clock ticks that are early, or late, can be adjusted, rather than being just 50-50.
[/quote]
thelizard
Timmy wrote:

thelizard wrote:
Seq-seis: Sequencer with six steps. Counting modes could be forwards, backwards, ping-pong, random, etc. Clock could be strobed, triggered, or burst generated. Perhaps individual steps could have multiplied outputs? This could behave similarly to the original Stillson Hammer (http://www.theharvestman.org/1974.php). Could also emulate something like the Turing Machine's Pulses expander in that a single LFSR could be used to sequentially address the six outputs (instead of how the LFSR mode is currently on a per-Clock channel basis).


So that would output a CV on channel 4 (D), and maybe triggers gates on the other channels? Why six steps?


No, it's a sequential trigger train, kind of like a Doepfer A-161 or Stillson Hammer. Essentially, the first trigger in sends a trigger out on Out1. The next trigger sends a trigger out on Out2. My "individual outs having multiplied outs" was a thought where perhaps Out 1 could bang once, Out 2 could bang four times at 4x rate. That way, you could perhaps have a kick always triggered once, and a snare always flammed with two hits or buzzed with eight.


Timmy wrote:

All those sound great. Internal patching of outputs to inputs via a mod-matrix makes sense.

Going beyond hard logic to fuzzy logics might also be possible. In other words, implementing neural nets. A number of NN topologies could be implemented, with various activation and transfer functions. Has anyone implemented a neural network rhythm source yet? It could be the first. I would suggest prototyping on a PC in an existing NN framework (there are many) to make sure it is useful and musical in some fashion.


Definitely, although I'm not an expert as far as implementing something like that. Here's an article on a recent project: https://medium.com/@granttimmerman/algo-rhythm-music-composition-using -neural-networks-f89897ff2df7#.7ujqrg8bx

In a similar vein (machine learning), are you still planning on porting Grids as a TU app?

Timmy wrote:

thelizard wrote:

-I'm toying with the idea of clock jitter as well. One of my favorite SuperCollider uGens for microsound is a clock with Gaussian disturbances. It stays fairly close to the main tempo, but provides a very pleasant amount of organic failure.


Even better if the mean and the variance of the Gaussian jitter are voltage-controllable, so that timing can be modulated from tight to sloppy in various ways. Maybe add a skewness parameter too (see Branches discussion above) so that the proportion of clock ticks that are early, or late, can be adjusted, rather than being just 50-50.


That would be great. I'll look into implementing that.
mxmxmx
Timmy wrote:
thelizard wrote:
Here are a few proposals for apps and upgrades that I want to work on:

Apps (with O+C style pun groaners):


Punning app names are de rigeur. Given the French name of the module, Oulipo-style jeux de mots get extra points...


he, i knew you were going to be delighted. 6clocks won't cut it, i suppose...


thelizard wrote:
Feature Improvements for 6xClocks/All Modes:
-Add all outputs as input trigger sources for individual clocks. For instance, Clock 2 could be triggered by the output of Clock 1 (instead of Trig input 1/2/Int). One of my favorite QCD tricks is to cascade the clocks into each other. Changing the clock at the top of the chain has dramatic effects on the rest.
-Add all outputs as modulation sources. For instance, Clock 2's Mult can be targeted by the output of Clock 1 (instead of, say, CV 1).
-Break out the multiplier logic into its own class so that it's more easily re-usable between apps.
-Break out logic operations (AND, OR, etc.) into a static class. Allow three-operator logical operations (maybe more?). Maybe add C-Gate, although that would require history.
-DAC Mix mode: Mixes the outputs of Clocks 1, 2, 3, 5, and 6 with bipolar levels. Allows you to create weird sequences from existing clock outputs.


make sense to me. #1 was on my list for the DAC channel. it'll be useful to have that in sync with some other channel to trigger an ADSR or the like; in which case that should be easy, because (as things are) channel #4 is updated last. that was mainly because of the "5-bit" sequencer (which might be similar to DAC Mix mode?), which needs to know the state of the other outputs; but i don't quite see how that'll work in general or consistently ... ie, triggering channel #6 by #1 will work, routing channel #6 into #1 will be one step behind. there's similar issues with logic, of course.


Timmy wrote:

Going beyond hard logic to fuzzy logics might also be possible. In other words, implementing neural nets.



considering the name of the module, something nerve-themed would only be appropriate, of course ...

nevetsokyeron
thelizard wrote:

Nope, not yet. However, Modular Addict has TU and O+C Panels in stock:
http://modularaddict.com/oscillosaurus-tempsutile-panel

Magpie recently started stocking O+C panels and PCBs, so maybe they'll carry TU soon? http://magpie-modular.myshopify.com/collections/murdered-out-modules/p roducts/pre-order-ornament-crime-panels-pcbs


Kris at Magpie said he did not have TU on his radar yet (so no PCBs or Panels for awhile). I've got Magpie O+C PCBs and Panel coming my way in the post right now. smile

I'll do some research later and see if I can order a batch of TU PCBs.
Timmy
thelizard wrote:
Timmy wrote:

thelizard wrote:
Seq-seis: Sequencer with six steps. Counting modes could be forwards, backwards, ping-pong, random, etc. Clock could be strobed, triggered, or burst generated. Perhaps individual steps could have multiplied outputs? This could behave similarly to the original Stillson Hammer (http://www.theharvestman.org/1974.php). Could also emulate something like the Turing Machine's Pulses expander in that a single LFSR could be used to sequentially address the six outputs (instead of how the LFSR mode is currently on a per-Clock channel basis).


So that would output a CV on channel 4 (D), and maybe triggers gates on the other channels? Why six steps?


No, it's a sequential trigger train, kind of like a Doepfer A-161 or Stillson Hammer. Essentially, the first trigger in sends a trigger out on Out1. The next trigger sends a trigger out on Out2. My "individual outs having multiplied outs" was a thought where perhaps Out 1 could bang once, Out 2 could bang four times at 4x rate. That way, you could perhaps have a kick always triggered once, and a snare always flammed with two hits or buzzed with eight.


Ah, OK, now I understand. Unfamiliar with the Stilton hammer (although I have often used a Stillson wrench as a hammer, which is the point, I suppose).

Timmy wrote:

All those sound great. Internal patching of outputs to inputs via a mod-matrix makes sense.

Going beyond hard logic to fuzzy logics might also be possible. In other words, implementing neural nets. A number of NN topologies could be implemented, with various activation and transfer functions. Has anyone implemented a neural network rhythm source yet? It could be the first. I would suggest prototyping on a PC in an existing NN framework (there are many) to make sure it is useful and musical in some fashion.


thelizard wrote:
Definitely, although I'm not an expert as far as implementing something like that. Here's an article on a recent project: https://medium.com/@granttimmerman/algo-rhythm-music-composition-using -neural-networks-f89897ff2df7#.7ujqrg8bx

In a similar vein (machine learning), are you still planning on porting Grids as a TU app?


Shall read that paper. Re Grids, yes. There's also this: http://www.mitpressjournals.org/doi/abs/10.1162/COMJ_a_00343?journalCo de=comj#.V8d32WW0ytk - I can send a pre-press copy of the full paper if you can't access it. They are locals.

Timmy wrote:

thelizard wrote:

-I'm toying with the idea of clock jitter as well. One of my favorite SuperCollider uGens for microsound is a clock with Gaussian disturbances. It stays fairly close to the main tempo, but provides a very pleasant amount of organic failure.


Even better if the mean and the variance of the Gaussian jitter are voltage-controllable, so that timing can be modulated from tight to sloppy in various ways. Maybe add a skewness parameter too (see Branches discussion above) so that the proportion of clock ticks that are early, or late, can be adjusted, rather than being just 50-50.


thelizard wrote:
That would be great. I'll look into implementing that.


Just one LUT with interpolation for a Gaussian distribution of mean zero and variance one. Then use simple scaling to change the variance and simple addition/subtraction to change the mean. Use the existing Peaks LUT and interpolation machinery. And CV control over shifting of the mean and of the variance. Forget the skew. That way no computation beyond addition and multiplication is required, which is a lot less fiddly than creating the distribution on the fly without hardware FP.
Timmy
mxmxmx wrote:
Timmy wrote:
thelizard wrote:
Here are a few proposals for apps and upgrades that I want to work on:

Apps (with O+C style pun groaners):


Punning app names are de rigeur. Given the French name of the module, Oulipo-style jeux de mots get extra points...


he, i knew you were going to be delighted. 6clocks won't cut it, i suppose...


How about "Sex urn"? That's six clocks in German as pronounced by an Australian... OK, maybe not.
Timmy
mxmxmx wrote:
considering the name of the module, something nerve-themed would only be appropriate, of course ...



"Nutzzeit" might be an appropriate name for 6clocks, which is the premier app, and thus its name would echo the name of the module?
mxmxmx
Timmy wrote:

"Nutzzeit" might be an appropriate name for 6clocks, which is the premier app, and thus its name would echo the name of the module?


well, that sounds a bit ... German. which is why i went for the French term; there's no real English equivalent either. (in fact, British scientist mostly just hated it, esp. the more infamous "chronaxie")




(anti-Lapicque poem, ca. 1932)
sockmonkey
mxmxmx wrote:
Timmy wrote:

"Nutzzeit" might be an appropriate name for 6clocks, which is the premier app, and thus its name would echo the name of the module?


well, that sounds a bit ... German. which is why i went for the French term; there's no real English equivalent either. (in fact, British scientist mostly just hated it, esp. the more infamous "chronaxie")
(anti-Lapicque poem, ca. 1932)


How about "Scissors", a brutal anglicisation of "six (fr) uhr (de)"?
diablojoy
Sex urn sounds good to me applause
Timmy
diablojoy wrote:
Sex urn sounds good to me applause


It holds the ashes of all those relationships that never proceeded past the physical...

Or "Sex urine" is even closer to the German, and may appeal to those who are into water sports. Now, where did I put my copy of Havelock Ellis?
Timmy
mxmxmx wrote:
Timmy wrote:

"Nutzzeit" might be an appropriate name for 6clocks, which is the premier app, and thus its name would echo the name of the module?


well, that sounds a bit ... German. which is why i went for the French term; there's no real English equivalent either. (in fact, British scientist mostly just hated it, esp. the more infamous "chronaxie")




(anti-Lapicque poem, ca. 1932)


Hmmm, "Chronaxie" might be a suitable name.
Altitude909
Timmy wrote:



..
Or "Sex urine" ..


paging mr. metasonix!
mxmxmx
Altitude909 wrote:
Timmy wrote:

..
Or "Sex urine" ..


paging mr. metasonix!


... i'll sleep over it.

here's my TODO list before releasing this properly:

- expand to div/16
- offset for division
- add mathematical division
- additional/internal trigger sources for DAC mode: channels 1-3, 5, and 6
- expand BPM base options (8th, 16th, PPQN24, 48?, 96?)
- review reset
- (re)implement trigger delay / configurable latency (--> reset)
- SEQ mode: disentangle editor/sequence selection; add modulation options (advance by trigger); and options to chain patterns.

in the meantime, if you come across any bugs, undesirable behaviour, etc, in the dev branch, ... please let me know.
toneburst
Software updates sound great!

Would this Farnell part part work as the inductor?

a|x
Timmy
toneburst wrote:
Software updates sound great!

Would this Farnell part part work as the inductor?

a|x


I used this: http://onecall.farnell.com/murata/lqh31mn100k03l/inductor-1206-case-10 -h-10/dp/1515424
mxmxmx
toneburst wrote:


Would this Farnell part part work as the inductor?


yes, should be ok. fwiw, the BOM including parts # is here; it comes with the one Tim mentioned.
toneburst
Good to know. I've ordered the one I mentioned, along with the other components.

I was working from the BIM on GitHub, though, so hope I ordered the right parts.

a|x
thelizard
I'm going to wait until the T_U firmware reaches its stable milestone until I start hacking away at it. Keep the merge chaos to a minimum =)

In the meantime, I've started work on "Panther," an O+C app that ports the functionality of the Malekko/Wiard JAG. It takes in two CV inputs (X and Y) and outputs voltages that are distances from the input position.

I just posted a pull request for what I *think* is a minor bug in the References app. I'm only mentioning it because I want to make sure that I'm understanding the general structures of the apps and app storage correctly. Essentially, it looks like a signed setting is being saved as an unsigned setting:
https://github.com/mxmxmx/O_C/pull/2
mxmxmx
thelizard wrote:
I'm going to wait until the T_U firmware reaches its stable milestone until I start hacking away at it. Keep the merge chaos to a minimum =)


yeah, sorry i guess i should have merged first, then proceed. but it's nearing that point, as far as i'm concerned; i haven't heard of lots of terrible bugs and there's only a few items left on my list.

mainly i'm still undecided about some of the feature requests, ie how to nicely integrate them with the UI at this point; mathematical division could be added as a separate mode, i suppose, less conveniently so as part of the core menu scheme. PPQN output might simply end up as a special case multiplication setting, it probably doesn't warrant a dedicated mode. offset is more obvious.

an up-to-date quick guide can be found here btw, the most recent changes are mostly additions to the trigger sequencer mode, which now supports patterns up to 64 length and some additional 'playmodes'
dusk
ordering parts now, can't wait to dive into it!
Sinamsis
I'm loving this module so far (and I'm still learning). Out of curiosity, is there any reason we're limiting divisions to 16 rather than 32? Not a deal breaker by any means, but I actually do use the /32 on my QCD from time to time, which I plan on replacing with a second TU when it's built.
mxmxmx
Sinamsis wrote:
I'm loving this module so far (and I'm still learning). Out of curiosity, is there any reason we're limiting divisions to 16 rather than 32?

you mean when i get round to expanding it from /8? no, it can go up to /32 or more. one question is which divisors to actually include; but i suppose why not à la QCD, something like 1/2/3/4/5/6/7/8/16/32/64? i also meant to change the way the settings-update works in this case, ie update only when pushing the encoder, not when scrolling.

in the meantime, though that's a bit more complicated, you could achieve a similar effect of course with the sequencer mode; ie make a pattern with just one trigger, length = 16, and divide by 2, that should give /32. with. div = /8, playmode = SEQ+4, and all patterns cleared except one trigger, you'd get /512 even.
Sinamsis
mxmxmx
Yes, that's what I was responding to, sorry. Wasn't sure if there was some hardware or software limitation in terms of how far the TU could divide.

I haven't played with the sequencer mode yet, but it sounds like that will open up a lot of other possibilities, so I'll check that out.

I am loving the Euclidean mode btw. Fantastic!
Timmy
This, from the burgeoning Temps utile user manual, struck a chord with me:

Quote:
NB: since the channels are processed sequentially, rather than in some quantum-entangled fashion, the result of the logic operation may not reflect the current output-state of the operand channels;


Clearly TU has some catching-up to do with those Qu-Bit modules.
mxmxmx
Sinamsis wrote:
mxmxmx
Yes, that's what I was responding to, sorry. Wasn't sure if there was some hardware or software limitation in terms of how far the TU could divide.


no problem at all ... in the version as is, it's indeed a bit of a software limitation, but there's no need to handle the divisions like that.

Sinamsis wrote:

I haven't played with the sequencer mode yet, but it sounds like that will open up a lot of other possibilities, so I'll check that out.

I am loving the Euclidean mode btw. Fantastic!


yeah, as far as the new features go, the sequencer is by far the neatest, i think. if you're familiar with the O&C scale editor, it should be fairly straightforward; it's basically a bastardization of that, so usage is much the same. the four "USER" patterns are entirely per channel, rather than shared across them (as would be the O&C USER scales), so plenty of options there.

and cool, IIRC Tim actually found some slightly odd behaviour in this particular Euclidian algorithm, which is just a one liner, when compared to the typical/correct and rather unwieldy implementations ... might fix that eventually, but it doesn't seem a huge issue.
dusk
Timmy wrote:
nevetsokyeron wrote:
I spent some time earlier finding Mouser part numbers for most of the stuff in the BOM.

Maybe this will be useful for others. If anyone has replacement part suggestions, please let me know.

279-1623096-1 100R 0805
603-RC0805JR-07510RL 510R 0805
667-ERA-6AED102V 1k 0805
667-ERA-6AED122V 1.2k 0805
754-RG2012P-182DT5 1.8k 0805
667-ERA-6AED302V 3k 0805
667-ERA-6AED392V 3.9k 0805
667-ERA-6AED682V 6.8k 0805
660-RK73H2ATTD1002F 10k 0805
756-PCF0805R-24K9BT1 20k 0805
660-RK73H2ATTD3302F 33k 0805
660-RK73H2ATTD1003F 100k 0805

81-GRM40C102J50D 1nF Ceramic Capacitor 0805
81-GRM215C1H332JA01D 3.3nF Ceramic Capacitor 0805
81-GRM21B5C1H183JA1L 18nF Ceramic Capacitor 0805
80-C0805C104K5R 100nF ceramic Capacitor 0805
77-VJ0805Y474JXJTBC 470nF ceramic Capacitor 0805
581-08055C105K4Z2A 1uF ceramic Capacitor 0805
81-GRM21BR6YA106KE3L 10uF ceramic (or tantal) Capacitor 0805
81-GRM39X103K50D 10nF Ceramic Capacitor 0603

595-TL074CDR TL074 (SOIC-14)
579-MCP6004T-I/SL MCP6004 (SOIC-14)
512-MMBT3904 MMBT3904 (NPN) (SOT-23)
621-1N5817 1N5817 (diode) (DO-41)
511-LD1117S50 LM1117-50 (SOT-223)
926-LM4040DIM350NOPB LM4040 5v0 (SOT-23)
81-LQH31MN100J03L Fixed inductor, 10uH (1206)

647-UPM1V220MDD1TD 22uF cap - RM2.5 (35V or better)
581-TAP474K035CCS 470nf 5mm - film/ceramic , 35v / 0.47uF
511-L78L33ACZ TO-92 3.3v regulator
517-929870-01-08-RA 1x7 (1x8) OLED socket - 2.54mm, **low profile** !
642-5GTH935 Tact switches - multimecs 5E/5G
642-1SS09-15.0 Switch caps - multimecs 1SS09-15.0 or -16.0

PEC11R-4215K-S0024 encoders - 24 steps w/ switch
649-67996-410HLF 2x5 pin header - 2.54mm (euro power connector)
571-15342372 1x14 socket - 2.54mm, socket for teensy 3.x


The majority of the parts are the same as in O&C. Just use the Mouser part numbers from the O&C BOM and you won't go wrong. Then you only need to find Mouser part numbers for the parts that differ from O&C.



279-1623096-1 100R 0805

this part has a minimum of 5000... anyone know of an alternate part? alternatively.. they are .0004 cents each.. I could buy a lot and send them out to people who need them? what do you guys think?
mxmxmx
dusk wrote:


279-1623096-1 100R 0805

this part has a minimum of 5000... anyone know of an alternate part? alternatively.. they are .0004 cents each.. I could buy a lot and send them out to people who need them? what do you guys think?


ups. there's plenty though. i'd get 100x of, say, 603-RC0805FR-07100RL
dusk
cool, thanks max. gonna go through the list of o+c and this and create a list and ask any other questions
dusk
mxmxmx wrote:
dusk wrote:


279-1623096-1 100R 0805

this part has a minimum of 5000... anyone know of an alternate part? alternatively.. they are .0004 cents each.. I could buy a lot and send them out to people who need them? what do you guys think?


ups. there's plenty though. i'd get 100x of, say, 603-RC0805FR-07100RL


100x? the docs only call for one, correct? are you saying grab 100... just to have?
thelizard
dusk wrote:
mxmxmx wrote:
dusk wrote:


279-1623096-1 100R 0805

this part has a minimum of 5000... anyone know of an alternate part? alternatively.. they are .0004 cents each.. I could buy a lot and send them out to people who need them? what do you guys think?


ups. there's plenty though. i'd get 100x of, say, 603-RC0805FR-07100RL


100x? the docs only call for one, correct? are you saying grab 100... just to have?


Take a look at Mouser's price breaks on each product page. With most resistors, it's cheaper to buy 10 than 1. It tends to cost only slightly more to upgrade to 100 instead of 10. 100 seems to be the sweet spot for most resistor purchases.

When working with SMD, always order extras on resistors and caps. If you drop them, sometimes they simply vanish from the physical realm. Plus, having extra stock means future projects are cheaper.
mxmxmx
dusk wrote:

100x? the docs only call for one, correct? are you saying grab 100... just to have?


yes, what thelizard said. just to have. you need 4x 100R: if you get four they cost 0.364 euro, a hundred cost 0.50 euro. so why not. depending on what other projects you plan to do though, it might make more sense of course to stock up on 0603.
dusk
mxmxmx wrote:
dusk wrote:

100x? the docs only call for one, correct? are you saying grab 100... just to have?


yes, what thelizard said. just to have. you need 4x 100R: if you get four they cost 0.364 euro, a hundred cost 0.50 euro. so why not. depending on what other projects you plan to do though, it might make more sense of course to stock up on 0603.


ok ya, I figured it was something like this, just want to make sure! thanks guys. smile
dusk
mxmxmx wrote:
dusk wrote:

100x? the docs only call for one, correct? are you saying grab 100... just to have?


yes, what thelizard said. just to have. you need 4x 100R: if you get four they cost 0.364 euro, a hundred cost 0.50 euro. so why not. depending on what other projects you plan to do though, it might make more sense of course to stock up on 0603.


going through the list now.. what is the part number for

1x14 + 1 sockets+headers

do any of these match?

http://www.mouser.com/Search/Refine.aspx?Keyword=1x14+%2b+1+sockets%2b headers
Timmy
The dagger in that row of the BOM table refers you to this footnote:

(†) also see the build guide: we need 14 pins on either side plus the DAC pin, so best to simply use 14 on the one side, and 13 + 2 on the other. the PCBs holes are small, so best to use so-called "machine" pin sockets + pin strip to match.

At the top of the "build it" page in the wiki there are links to suitable parts on eBay. If you look in the BOM for O&C there is a link to an alternative socket that fits nicely and accepts standard 0.1 inch square pin headers - that what I use. It is only available from RS-Online AFAIK, not Mouser. I don't think Mouser carry suitable sockets for the Teensy. They do have a suitable low profile socket for the OLED - see the O&C BOM. There is also discussion of this in the O&C thread on MW.
mxmxmx
dusk wrote:


going through the list now.. what is the part number for

1x14 + 1 sockets+headers


as Tim said, take a look here: https://github.com/mxmxmx/temps_utile-/wiki/build-it#bom

i haven't included a part # in the BOM because this kind of thing is so $ when bought from mouser.

also fwiw, this latest branch adds more division options: /64, /48, /32, /16, as well as a few minor fixes.
dusk
Timmy wrote:
The dagger in that row of the BOM table refers you to this footnote:



this is my first time ordering parts + building anything like, so really appreciate the help, gentlemen!
gwpt
Hi,
Don't suppose anyone has a spare utile temps
Pcb?
Thanks
mxmxmx
gwpt wrote:
Hi,
Don't suppose anyone has a spare utile temps
Pcb?


i have

walkindude125
Could you also put me down for a temps utile pcb?? I'd love to start building one!

Also, I was looking at the older O_C thread, and you happen to mention that the MEC 5GTH935 Switches work, but can I use the illuminated ones (5GTH93522) or will the board not support an LED switch?

Thanks in advance for your help!
mxmxmx
walkindude125 wrote:
Could you also put me down for a temps utile pcb?? I'd love to start building one!

Also, I was looking at the older O_C thread, and you happen to mention that the MEC 5GTH935 Switches work, but can I use the illuminated ones (5GTH93522) or will the board not support an LED switch?


they should/will work as a switch, in place of 5GTH935, but i think that comment was only because someone accidentally bought the illuminated ones. there's no signal for the LED, nor is there any code supporting illuminated switches. i suppose you could, if you absolutely wanted to, hack up something and wire some of the spare teensy pins to the anode pin. and then integrate that with the UI / code.

the transparent caps that go with the illuminated switches (they fit the non-illuminated ones, too) are nice though with dirkwiggler's black panels:




pm'd you re PCBs
nevetsokyeron
Has anyone tried using a Teensy 3.0 with the tempsutile?

I've got 2-3 of those sitting around unused and wondered if there's any issues to be aware of.

Thx!
nevetsokyeron
nevetsokyeron wrote:
Has anyone tried using a Teensy 3.0 with the tempsutile?


Maybe answering my own question...

The Teensy 3.0 does not have the onboard DAC on pin A14 - which appears to be required for TempsUtile. Is that correct?

If so, documentation should be updated to reflect that Teensy 3.1 or 3.2 is required rather than "Teensy 3.x" (which is listed as such at https://github.com/mxmxmx/temps_utile-/wiki/Temps-Utile)
Timmy
nevetsokyeron wrote:
Has anyone tried using a Teensy 3.0 with the tempsutile?

I've got 2-3 of those sitting around unused and wondered if there's any issues to be aware of.

Thx!


The pins are not the same as the 3.1/3.2. In particular, there is no DAC output pin, so channel 4 would not work. Then you'd need to adjust all the timings since it runs at a much slower clock speed. Then the firmware may crash due to out of memory errors because it has only a quarter as much RAM. And later versions of the firmware may not fit because it has only half as much flash storage.

So, in summary: yes there are major issues. The current and all future versions of TU firmware is designed around the Teensy 3.1. It works fine with the Teensy 3.2 but not any Teensy versions earlier than 3.1.
mxmxmx
nevetsokyeron wrote:
nevetsokyeron wrote:
Has anyone tried using a Teensy 3.0 with the tempsutile?


Maybe answering my own question...

The Teensy 3.0 does not have the onboard DAC on pin A14 - which appears to be required for TempsUtile. Is that correct?

If so, documentation should be updated to reflect that Teensy 3.1 or 3.2 is required rather than "Teensy 3.x" (which is listed as such at https://github.com/mxmxmx/temps_utile-/wiki/Temps-Utile)


well, 3.0 has been unavailable since late 2013 or so.

anyways, you should be able to use it, at least in terms of hardware: that's what the pad labelled '29' is for, and the 3-pins/jumper 'CLK/DAC'. the current firmware won't work as is, though. you'd have to make channel 4 use pin 29 and disable all the DAC specific things. and as Tim says, there might be other incompatibilities, i haven't tried/don't know.
nevetsokyeron
mxmxmx wrote:
well, 3.0 has been unavailable since late 2013 or so.


Yup. But I have three of them sitting around unused. I'll just re-allocate them to various Blinky-Lights projects smile

mxmxmx wrote:
anyways, you should be able to use it, at least in terms of hardware: that's what the pad labelled '29' is for, and the 3-pins/jumper 'CLK/DAC'. the current firmware won't work as is, though. you'd have to make channel 4 use pin 29 and disable all the DAC specific things. and as Tim says, there might be other incompatibilities, i haven't tried/don't know.


Not a problem. Mostly I think it would be good to update the documentation page I mentioned to remove "3.x" and explicitly state 3.1/3.2 is required.
mxmxmx
nevetsokyeron wrote:

Not a problem. Mostly I think it would be good to update the documentation page I mentioned to remove "3.x" and explicitly state 3.1/3.2 is required.


et voilà. probably a good idea now that 3.x might be read as 3.5 or 3.6, neither of which will fit.
jcarruthers
Anyone got any ideas where to get a PCB for this?
toneburst
Hi James.

Talk nicely to mxmxmx- he often has some in stock.
I built one a couple of weeks ago, if you want to see how it works.
Firmware is very much in development at the moment (but already very cool).

a|x
nevetsokyeron
Re: the 470nF cap

Is there any functional difference between using a ceramic cap versus the box type (are these the film caps?) ?

The BOM says film or ceramic I think. One of the pictures on github shows a ceramic and the build guide shows a box-type. The ceramic seems to be on an earlier board revision since it also shows the trimmer.

Gonna finish up a couple of these tonight and wanna confirm I'll be OK with the ceramic caps I have.

thx!
mxmxmx
nevetsokyeron wrote:
Re: the 470nF cap

Is there any functional difference between using a ceramic cap versus the box type (are these the film caps?) ?


none, the footprint is 5mm, so a box type might fit better, that's all.
nevetsokyeron
Finished these two babies up tonight!



I loaded the firmware via the hex file in the github Master branch - the functions in this version do not seem to match up with the documentation. Is there a particular branch of the code that would be more in sync with the docs?
mxmxmx
nevetsokyeron wrote:

I loaded the firmware via the hex file in the github Master branch - the functions in this version do not seem to match up with the documentation. Is there a particular branch of the code that would be more in sync with the docs?


yep, see here: https://github.com/mxmxmx/temps_utile-/wiki/firmware
nevetsokyeron
Ah.. that's what I get for not actually reading all the docs. d'oh!

So I went ahead and tried devdev_SEQ_RESET

Found what might be a bug (text-error on screen):

When selecting clock source, rotating all the way to right right gives me this garbled text next to /+#

mxmxmx
nevetsokyeron wrote:
Ah.. that's what I get for not actually reading all the docs. :doh:

So I went ahead and tried devdev_SEQ_RESET


he, though the docs say
Quote:
clone from https://github.com/mxmxmx/temps_utile-/tree/fix_6_11
nevetsokyeron
Apologies... I loaded the devdev_SEQ_RESET before I came back and saw your post that fix_6_11 is the one to use.

If I do try a dev version, what is your preferred method of reporting bugs/problems? Open an issue on github?
mxmxmx
nevetsokyeron wrote:

If I do try a dev version, what is your preferred method of reporting bugs/problems? Open an issue on github?


i don't mind, either is fine.
nevetsokyeron
From the calibration documentation page:
Quote:
3. DAC/channel 4
connect your multimeter to the channel 4 output (typically using alligator clip connectors on a patch cable inserted in the channel A jack, or some other equivalent arrangement), and twist the right encoder until you see ~ 0.0 volts on the DAC output.


Should this be "patch cable inserted in the channel D jack" rather than "A"?
mxmxmx
nevetsokyeron wrote:
From the calibration documentation page:
Quote:
3. DAC/channel 4
connect your multimeter to the channel 4 output (typically using alligator clip connectors on a patch cable inserted in the channel A jack, or some other equivalent arrangement), and twist the right encoder until you see ~ 0.0 volts on the DAC output.


Should this be "patch cable inserted in the channel D jack" rather than "A"?


yep, sorry i just copy+pasted most of this from the OC how-to. fixed now. the DAC channel is "D" or "4", ie depending on labels
nevetsokyeron
Curious about internal clocks...

in MULT/DIV mode with multiple channels set to individually to INT clocks, it sounded like they all were just a little off in time (slightly flanging in output order i think)

When set to TR1 and sending clock, timing sounded nice and tight.

Just did another test - all channels set to INT clock on MULT and everything seems out of sync.

Is this by design? Is there a way to sync all the clocks together internally?
nevetsokyeron
OK...

I found this in the docs:
"pushing the left encoder once will re-sync the channels."

However, this does not sync the channels for me. It just takes me from the screensaver back to the menu.
mxmxmx
nevetsokyeron wrote:


Is this by design? Is there a way to sync all the clocks together internally?


can you try this? (i'm out of town atm, so haven't tested this, but should fix it)
nevetsokyeron
mxmxmx wrote:

can you try this? (i'm out of town atm, so haven't tested this, but should fix it)


Hi Max,

That does seem to fix it. (or some of it)

(quick test) If I long-press-down to set clock to TR1, then long-press-up to set all clocks to INT, then they appear to be blinking in sync on the display.

However... When I change an individual channel's MULT/DIV amount it seems that clock can get out of sync with the others.

At this point, pushing the left encoder once does NOT re-sync the INT clocks. I need to do the long-press-down/long-press-up to get them all synced.
mxmxmx
nevetsokyeron wrote:
mxmxmx wrote:

can you try this? (i'm out of town atm, so haven't tested this, but should fix it)


Hi Max,

That does seem to fix it. (or some of it)

(quick test) If I long-press-down to set clock to TR1, then long-press-up to set all clocks to INT, then they appear to be blinking in sync on the display.

However... When I change an individual channel's MULT/DIV amount it seems that clock can get out of sync with the others.

At this point, pushing the left encoder once does NOT re-sync the INT clocks. I need to do the long-press-down/long-press-up to get them all synced.


ok, i'll look at it when i get back, i'm at some conference.

fwiw, nothing changed re long-pressing up/down, that should be fine because it sets the clock source for all channels at the the same time. however, when setting the clock source for channels individually, the internal clocks will be out of sync, because each channel will start counting basically from the moment its clock source parameter was set to internal; that's not really intended. the fix linked above should have fixed that. if it doesn't, i guess i'll have to fix some more.
nevetsokyeron
mxmxmx wrote:

fwiw, nothing changed re long-pressing up/down, that should be fine because it sets the clock source for all channels at the the same time. however, when setting the clock source for channels individually, the internal clocks will be out of sync, because each channel will start counting basically from the moment its clock source parameter was set to internal; that's not really intended. the fix linked above should have fixed that. if it doesn't, i guess i'll have to fix some more.


Yeah... the new fix you posted did not entirely fix the individual channel syncing.
nevetsokyeron
Some basic wiggling tonight...

(internal clocks MULT/DIV with one SEQ)

mxmxmx
nevetsokyeron wrote:

Yeah... the new fix you posted did not entirely fix the individual channel syncing.


ok, just to make sure though: you've actually tried with the new commit from yesterday, right? that should reset all relevant counters whenever you change from external to internal clock, i'm not sure why it wouldn't.
nevetsokyeron
mxmxmx wrote:

ok, just to make sure though: you've actually tried with the new commit from yesterday, right? that should reset all relevant counters whenever you change from external to internal clock, i'm not sure why it wouldn't.


Yes yes. Used the new commit. I didn't see the problem again tonight until just after I made that video - had channel six doing offbeats when it should have been on-beat (1s).

Note - this was while it was running and I changed just channel 6 from INT to none I think. Then back to INT.

FWIW - the counters do all reset and sync when you switch everything from EXT to INT with the long-down-press (which it did not do in the previous version)

I can try again tomorrow to isolate something reproducible.
mxmxmx
nevetsokyeron wrote:

Yes yes. Used the new commit. I didn't see the problem again tonight until just after I made that video - had channel six doing offbeats when it should have been on-beat (1s)


ah, ok. but that means they're in sync, timing wise. the commit addressed a different issue ("slightly flanging in output order"), which i think it should fix. that's unrelated to off/on-beats; you should be able to resync the dividers by pushing the left encoder
nevetsokyeron
mxmxmx wrote:
nevetsokyeron wrote:

Yes yes. Used the new commit. I didn't see the problem again tonight until just after I made that video - had channel six doing offbeats when it should have been on-beat (1s)


ah, ok. but that means they're in sync, timing wise. the commit addressed a different issue ("slightly flanging in output order"), which i think it should fix. that's unrelated to off/on-beats; you should be able to resync the dividers by pushing the left encoder


OK - perhaps I was not too precise in my terminology. I *think* it was off-beat, but it might not have been right in time. They were set to the same divider value, but were not synced. I'll need to test again to see for sure and make a video.

Unfortunately, left-encoder press does not do anything as far as I can tell. It does not bring the off-beat channel into sync.
nevetsokyeron
Ok - here's a few test videos.

Test 2: https://www.youtube.com/watch?v=MDi4pF3pBng
Test 3: https://www.youtube.com/watch?v=9uVut9_1hFU
Test 4: https://www.youtube.com/watch?v=b_WvAf3azow

There seem to be an issue when switching to/from MULT where the channel can end up on an off-beat. (around 1:05 in Test 2)

When in a MULT switching from INT to none does not stop the clock on that channel. Test 3 video (this works fine when using a divider)

Then also, when using a divider, all channels pause one beat when you switch a channel from none back to INT. Test 4 video

It seems everything stays in time, but think I managed to make it flange a little bit when I started. Still trying to reproduce that.

EDIT 10/8: I think I found a fix for the left-encoder-button press. I submitted that on GitHub.
n0rd
@mxmxmx, PM'ed you regarding PCBs. Cheers.
mxmxmx
n0rd wrote:
@mxmxmx, PM'ed you regarding PCBs. Cheers.


pm'ed you back. i don't have any at the moment, but have some on order. in 2-3 weeks, i guess.
gerald
Question about the OLED on the T_U vs. the O_C. I built up two of each, and the O_C OLED displays are brighter. The T_U seem to be trying to do grey-scale - the selected line is grey, and changes brightness as you scroll down to the bottom. Also, there is some display noise - letters shift left and right in a noisy - wavy manner that I haven't seen since the good old CRT days. This seems to happen when you rotate the encoders.

Now - none of this is a major concern. Does the T_U display use different pins - like that extra one underneath the Teensy? Or is the display software significantly different? I don't think it is something wrong with mine - or if it is, I am really good at doing something wrong twice, and right two more times with the O_C.

-gerald
mxmxmx
gerald wrote:
Question about the OLED on the T_U vs. the O_C. I built up two of each, and the O_C OLED displays are brighter. The T_U seem to be trying to do grey-scale - the selected line is grey, and changes brightness as you scroll down to the bottom. Also, there is some display noise - letters shift left and right in a noisy - wavy manner that I haven't seen since the good old CRT days. This seems to happen when you rotate the encoders.

Now - none of this is a major concern. Does the T_U display use different pins - like that extra one underneath the Teensy? Or is the display software significantly different? I don't think it is something wrong with mine - or if it is, I am really good at doing something wrong twice, and right two more times with the O_C.


is this the firmware in question?

anyways, yes, the pins are slightly different, but it shouldn't make a difference. the display driver / software is the same now, ie if using the dev branch, as per the build guide.
gerald
mxmxmx wrote:
is this the firmware in question?


Yes - I used that firmware. Is there a schematic in .pdf or .png format for the T_U somewhere? I could try to make a video to show what I'm talking about, but I'm not sure that would help much. Here is a photo just to show that it isn't that subtle a difference. The other two units look identical. Does the T_U power the OLED differently than the O_C - it almost looks current starved? If the highlighted line shouldn't have a "vertical gradient effect" then something is awry. It changes intensity as you scroll down. Identical OLED's from the same purchase.

nevetsokyeron
gerald wrote:
Question about the OLED on the T_U vs. the O_C. I built up two of each, and the O_C OLED displays are brighter. The T_U seem to be trying to do grey-scale - the selected line is grey, and changes brightness as you scroll down to the bottom. Also, there is some display noise - letters shift left and right in a noisy - wavy manner that I haven't seen since the good old CRT days. This seems to happen when you rotate the encoders.


FWIW - I don't see this on my 2 temps, but my friend giftculture is having a some display noise on his temps. (bottom of one row of text having a kind of fade/gradient of tone). Changing the display or the teensy did not have any effect.
nevetsokyeron
Swing...

So I had a crazy idea the other day... What if the TempsUtile could give us a swing (swung?) beat?

Roger Linn sez:
Quote:
My implementation of swing has always been very simple: I merely delay the second 16th note within each 8th note. In other words, I delay all the even-numbered 16th notes within the beat (2, 4, 6, 8, etc.) In my products I describe the swing amount in terms of the ratio of time duration between the first and second 16th notes within each 8th note. For example, 50% is no swing, meaning that both 16th notes within each 8th note are given equal timing. And 66% means perfect triplet swing, meaning that the first 16th note of each pair gets 2/3 of the time, and the second 16th note gets 1/3, so the second 16th note falls on a perfect 8th note triplet.


So tonight I sat with a friend who can code in C (whereas I'm very hackish) and we tried to decipher the APP_CLK code and figure out how to implement some swing.

I posted my results as an issue on the Github page. It's just a few lines of code, but we were not really sure if we are in the right place to monkey with the timing.

Is this a feature worth pursuing? I think it'd be kinda groovy to be able to CV control swing.
mxmxmx
gerald wrote:
Is there a schematic in .pdf or .png format for the T_U somewhere? I could try to make a video to show what I'm talking about, but I'm not sure that would help much. Here is a photo just to show that it isn't that subtle a difference. The other two units look identical. Does the T_U power the OLED differently than the O_C - it almost looks current starved? If the highlighted line shouldn't have a "vertical gradient effect" then something is awry. It changes intensity as you scroll down. Identical OLED's from the same purchase.


mmh, no, that doesn't look right. there's no schematic, the OLED bit is basically identical to OC though. except, the power supply situation is indeed somewhat different, there's the 78L33 right next to the OLED, which supplies the 3v3. OC uses the teensy onboard regulator. that shouldn't make a difference really, and i haven't come across that gradient effect thing. LM1117 can supply 800mA max, and 78L33 100mA max, so there shouldn't be an issue. .... in theory, if you removed the 78L33 and jumpered the teensy 3v3 pin to the 78L33 Vout pin, you'd end up with the same circuit as in OC. maybe worth trying, though there's no real rationale to it.


nevetsokyeron wrote:
Swing...

So I had a crazy idea the other day... What if the TempsUtile could give us a swing (swung?) beat?

[...]

Is this a feature worth pursuing? I think it'd be kinda groovy to be able to CV control swing.


sure, why not. quick look suggests it would have to look slightly more complicated, because division and multiplication are handled somewhat differently. (also integer math would be preferable to using floats, there's no FPU on this chip.) fwiw / alternatively, there's some trigger delay functionality in the OC code, which probably could be adapted. i'm fairly busy with real work atm, so can't do much about this right now.
nevetsokyeron
mxmxmx wrote:

sure, why not. quick look suggests it would have to look slightly more complicated, because division and multiplication are handled somewhat differently. (also integer math would be preferable to using floats, there's no FPU on this chip.) fwiw / alternatively, there's some trigger delay functionality in the OC code, which probably could be adapted. i'm fairly busy with real work atm, so can't do much about this right now.


Understood. I'll try to see if I can get any farther along on my own and will take a look at the OC code as well.

Thanks!
gerald
gerald wrote:
I don't think it is something wrong with mine - or if it is, I am really good at doing something wrong twice, and right two more times with the O_C. -gerald


Turns out I was right - I am really good at forgetting to solder in the 3.3V regulators on both T_U modules. Frickin' stupid mistake... but really easy to fix! They work/look great now.
nevetsokyeron
gerald wrote:

Turns out I was right - I am really good at forgetting to solder in the 3.3V regulators on both T_U modules. Frickin' stupid mistake... but really easy to fix! They work/look great now.


SlayerBadger! SlayerBadger! SlayerBadger!
sockmonkey
So I have a feature request, which I'll probably implement myself, but wanted to first see if anyone has thoughts about it. I was using the module extensively yesterday (in MULT mode) and in the heat of battle made a number of changes to the mult/div factor. After saving and power-cycling, it became clear that some of the channels had been out of sync with the trigger based on when they were changed.

That's fine (although I bet that could/should be fixed), but I lost my groove.

So I know there's a feature for resyncing, but what I want is a desync/offset parameter so that I can shift the position of my /6 against the incoming trigger. Not sure if this should be in increments of a user-defineable subdivision (like 32 positions per trigger), or in 'ticks'. Maybe both should be an option in order to flexibly program different kinds of offset effects.

Thoughts?

I've also added a number of addl div and mult factors in my fork, incl */ 12, 24 and 48 divisions, and adding *>8 factors (since I sometimes work with very slow tempi). I'd love to get some fractional factors in there, too, but the current implementation will only deal with whole numbers. A problem for another day...
mxmxmx
sockmonkey wrote:
So I have a feature request, which I'll probably implement myself, but wanted to first see if anyone has thoughts about it. I was using the module extensively yesterday (in MULT mode) and in the heat of battle made a number of changes to the mult/div factor. After saving and power-cycling, it became clear that some of the channels had been out of sync with the trigger based on when they were changed.

That's fine (although I bet that could/should be fixed), but I lost my groove.

So I know there's a feature for resyncing, but what I want is a desync/offset parameter so that I can shift the position of my /6 against the incoming trigger. Not sure if this should be in increments of a user-defineable subdivision (like 32 positions per trigger), or in 'ticks'. Maybe both should be an option in order to flexibly program different kinds of offset effects.

Thoughts?



yeah, that's an artefact of the channels being basically independent. as things are, rather than all outputs deriving from one timer (as in, say, RCD / SCM), they all come with their own counters, and things start dividing as soon as the mult/div parameter changes. i'm not sure how best to fix it, tbh; or what the offset would have to be relative to. the channel with the largest division factor?

sockmonkey wrote:

I've also added a number of addl div and mult factors in my fork, incl */ 12, 24 and 48 divisions, and adding *>8 factors (since I sometimes work with very slow tempi). I'd love to get some fractional factors in there, too, but the current implementation will only deal with whole numbers. A problem for another day...


pull requests welcome. ... re fractional factors: that should be doable though along the same lines. e.g. multiplier = (2^32 - 1) / 1.5 = 0xAAAAAAAA should yield 1.5x. i didn't come up with a good idea in terms of UI yet, but i was vaguely thinking it might make sense to provide different sets of divisors/multipliers, rather than cram them all into one setting: even, odd/even, maybe fractional.
sockmonkey
mxmxmx wrote:
sockmonkey wrote:
So I know there's a feature for resyncing, but what I want is a desync/offset parameter so that I can shift the position of my /6 against the incoming trigger. Not sure if this should be in increments of a user-defineable subdivision (like 32 positions per trigger), or in 'ticks'. Maybe both should be an option in order to flexibly program different kinds of offset effects.


yeah, that's an artefact of the channels being basically independent. as things are, rather than all outputs deriving from one timer (as in, say, RCD / SCM), they all come with their own counters, and things start dividing as soon as the mult/div parameter changes. i'm not sure how best to fix it, tbh; or what the offset would have to be relative to. the channel with the largest division factor?


If the channel-local counter were reset/auto-synced to 0 at incoming trigger time, wouldn't that solve the problem? There would be one "weird" cycle when changing the factor on the fly, but that could be avoided by buffering the change until the next trigger arrives.


Quote:
pull requests welcome. ... re fractional factors: that should be doable though along the same lines. e.g. multiplier = (2^32 - 1) / 1.5 = 0xAAAAAAAA should yield 1.5x. i didn't come up with a good idea in terms of UI yet, but i was vaguely thinking it might make sense to provide different sets of divisors/multipliers, rather than cram them all into one setting: even, odd/even, maybe fractional.


Cool. I had already added the hex factors until I realized that the divisors_ array is expecting a uint8_t. There would need to be a more complex notion of numerator/denominator-specified clock division in order to get 1.5 (3:2) division working. It may be possible to leave it all in one list, I guess. But user-specifiable fractional division (22:7 anyone?) would be wicked cool.
Jaypee
nevetsokyeron wrote:
Swing...

So I had a crazy idea the other day... What if the TempsUtile could give us a swing (swung?) beat?

Roger Linn sez:
Quote:
My implementation of swing has always been very simple: I merely delay the second 16th note within each 8th note. In other words, I delay all the even-numbered 16th notes within the beat (2, 4, 6, 8, etc.) In my products I describe the swing amount in terms of the ratio of time duration between the first and second 16th notes within each 8th note. For example, 50% is no swing, meaning that both 16th notes within each 8th note are given equal timing. And 66% means perfect triplet swing, meaning that the first 16th note of each pair gets 2/3 of the time, and the second 16th note gets 1/3, so the second 16th note falls on a perfect 8th note triplet.


So tonight I sat with a friend who can code in C (whereas I'm very hackish) and we tried to decipher the APP_CLK code and figure out how to implement some swing.

I posted my results as an issue on the Github page. It's just a few lines of code, but we were not really sure if we are in the right place to monkey with the timing.

Is this a feature worth pursuing? I think it'd be kinda groovy to be able to CV control swing.


THIS!!!!
masterofstuff124
is this the most up to date flashable hex?
https://github.com/mxmxmx/temps_utile-/tree/master/soft/hex

my newly built temps seems to be missing some functionality- no multiplication, calibration page seems incomplete, ive found mention of other functionality that I cant seem to find.

curious if its software or hardware as this is a fresh build.
keninverse
Try this branch:
https://github.com/mxmxmx/temps_utile-/tree/fix_6_11
masterofstuff124
thanks. but i dont see a hex file in there?
masterofstuff124
followed the instructions on the firmware page. all seems well now! thanks for the help~! nanners
mxmxmx
masterofstuff124 wrote:
followed the instructions on the firmware page.


road to success ... i suppose i could make the branch master though, to cause less confusion.
masterofstuff124
New problem though channel 2 and 4 don't seem to output anything. Need to figure out how to open the pcb files it isn't just the standard brd eagle stuff. And then I can trace those connections.
keninverse
I use Pentalogics' Viewmate for viewing gerbers. Works well.
nevetsokyeron
masterofstuff124 wrote:
New problem though channel 2 and 4 don't seem to output anything. Need to figure out how to open the pcb files it isn't just the standard brd eagle stuff. And then I can trace those connections.


Check the long row of resistors on either side of the TL074s. I had a resistor with one end not quite attached on one build that caused a similar problem for me IIRC.
mxmxmx
nevetsokyeron wrote:
masterofstuff124 wrote:
New problem though channel 2 and 4 don't seem to output anything. Need to figure out how to open the pcb files it isn't just the standard brd eagle stuff. And then I can trace those connections.


Check the long row of resistors on either side of the TL074s. I had a resistor with one end not quite attached on one build that caused a similar problem for me IIRC.


yeah, the channel 2 output should be easy to fix. it's just a non-inverting op-amp (see here); the op amp in question is right above the channel #2 jack, ie the left TL074, pins 1,2, and 3. should be easy to see on the PCB.

channel 4 is the DAC output, which is slightly more complicated. make sure you've actually connected the DAC pin (A14) and the jumper ("DAC"). the output stage is two multiple feedback filters in series:



that's using two op-amps from the right-hand TL074 (pins 1,2,3 and 5,6,7).

first stage: R1 = 3k9, R2 = 6k8, R3 = 3k, C1 = 1n, C2 = 3n3.
second stage: R1 = 1k8, R2 = 3k, R3 = 1k2, C1 = 1n, C2 = 18n.
dusk
well shit.. one of the resistors was reading 66k instead of 100k, so I desoldered it to pull it and ended up putting the contact lead as well.. :(

can I solder a jumper wire to where the other end of this resistor is supposed to connect to?

I cant find a schematic for this.. is it that little hole right next to it for 470n?

also.. another resistor is reading 166K instead of 100K and now im afraid to desolder and replace it.. it's the top horizontal 100K right under where the dac/teensy go...

crap, I hope I can salvage this, ive spent 4 hours on it so far smile

thanks for the help!

im gonna keep soldering in the caps and hopefully can save it

mxmxmx
dusk wrote:
well shit.. one of the resistors was reading 66k instead of 100k, so I desoldered it to pull it and ended up putting the contact lead as well.. :(

can I solder a jumper wire to where the other end of this resistor is supposed to connect to?

I cant find a schematic for this.. is it that little hole right next to it for 470n?


use a gerber viewer, you'll see where to/how to connect the one end of the 100k resistor to the one sitting right next to it.

dusk wrote:

also.. another resistor is reading 166K instead of 100K and now im afraid to desolder and replace it.. it's the top horizontal 100K right under where the dac/teensy go...

crap, I hope I can salvage this, ive spent 4 hours on it so far :)

thanks for the help!


4 hours? oh dear. fwiw, if it says '1003' on it chances are it's actually 100k, not 166k, so i'd leave it there for the time being.
dusk
mxmxmx wrote:
dusk wrote:
well shit.. one of the resistors was reading 66k instead of 100k, so I desoldered it to pull it and ended up putting the contact lead as well.. :(

can I solder a jumper wire to where the other end of this resistor is supposed to connect to?

I cant find a schematic for this.. is it that little hole right next to it for 470n?


use a gerber viewer, you'll see where to/how to connect the one end of the 100k resistor to the one sitting right next to it.

dusk wrote:

also.. another resistor is reading 166K instead of 100K and now im afraid to desolder and replace it.. it's the top horizontal 100K right under where the dac/teensy go...

crap, I hope I can salvage this, ive spent 4 hours on it so far smile

thanks for the help!


4 hours? oh dear. fwiw, if it says '1003' on it chances are it's actually 100k, not 166k, so i'd leave it there for the time being.


thanks for the reply!
its my first SMD build... taking it slow

what is the file i need to load in the gerber viewer?
mxmxmx
dusk wrote:


what is the file i need to load in the gerber viewer?


this zip file. you can use this one or use the oshpark preview, say. there's other options, but that'll do.

here is the relevant bit of the schematic.
dusk
excellent.. i soldered a jumper wire across to the resistor next to it, fingers crossed it'll work
shiftr
dusk wrote:
well shit.. one of the resistors was reading 66k instead of 100k, so I desoldered it to pull it and ended up putting the contact lead as well.. :(


You can't measure a resistor once it is soldered in a circuit!
You will never know if you are not also measuring other resistors and parts too following another path of the circuit. Enless you know very sure you are measuring an isolated part of the circuit.
So the 100k was probably just 100k measured with some parallel resistor also measured in the circuit.
dusk
thanks for the advice!

im on the output amplifier now.. but the TL074C doesnt have an indent in them.. is there a proper way to place these components? should i line the text up with the text on the pcb?
lasesentaysiete
dusk wrote:
is there a proper way to place these components?

yes. There should be a bevelled edge along the side of pin 1. Post a picture or check the datasheet if you're unsure.
dusk
thanks! ok have it all assembled and trying to load the firmware.. there is a light on the back of the teensy, but it's stuck in a loop of asking me to press button on teensy to manually enter program mode, i press the button it says REBOOT OK, then puts me back at the press button screen, and it loops endlessly.. any ideas?
dusk
prepare for a very ugly soldering job

https://i.imgur.com/Z0e43TS.jpg
Timmy
Clean off all that flux! Isopropanol and an old tooth brush and eye protection will do it.
dusk
heh, ok! i will clean it
dusk
cleaned it..it's still rebooting constantly when i press the program button
dusk
hmm. not connecting to the teensy anymore... not sure what happened https://vimeo.com/190463187

here is a video


edit!!! i noticed a lead on the teensy board i was using had come off somehow.. so i swapped it with the board i was going to use for oc... im connected to the teensy but it gets caught in a weirdo reboot cycle. i took a video

https://vimeo.com/190473348
mxmxmx
dusk wrote:

edit!!! i noticed a lead on the teensy board i was using had come off somehow.. so i swapped it with the board i was going to use for oc... im connected to the teensy but it gets caught in a weirdo reboot cycle. i took a video

https://vimeo.com/190473348


mmh, weird. i'd leave off the teensy for now. when you power the module without the teensy, do you get a solid 5V at the V_in pin?
dusk
mxmxmx wrote:
dusk wrote:

edit!!! i noticed a lead on the teensy board i was using had come off somehow.. so i swapped it with the board i was going to use for oc... im connected to the teensy but it gets caught in a weirdo reboot cycle. i took a video

https://vimeo.com/190473348


mmh, weird. i'd leave off the teensy for now. when you power the module without the teensy, do you get a solid 5V at the V_in pin?


yes 5v without teensay
nevetsokyeron
dusk wrote:

edit!!! i noticed a lead on the teensy board i was using had come off somehow.. so i swapped it with the board i was going to use for oc... im connected to the teensy but it gets caught in a weirdo reboot cycle.


Something to try so you can isolate if the issue is with the Teensy - Remove the Teensy from the Temps. Since you've cut the trace on the teensy, it will not get power from USB - you can solder a wire across those 2 pads where you cut the trace, and then plug the teensy in to your computer by itself to see it it will properly take the program.

I will manually hold a little wire jumper or something across those 2 pads to do this sometimes.

If the teensy takes the program OK - then I'd do some checking to be sure you don't have a short somewhere on the Temps board out from the teensy headers - which could be triggering the teensy reboot (?).

I'd probably check everywhere I can for bridges/shorts.
nevetsokyeron
dusk wrote:
prepare for a very ugly soldering job

https://i.imgur.com/Z0e43TS.jpg


FWIW - all of your header connections on the Teensy look inadequate - needs more solder. Hit ALL of those again and get the solder to flow entirely onto each pad/pin.

I'd suggest removing the Teensy from the Temps board when you do this so you're dispersing all the heat down the headers into the main board.
dusk
so i just built the O+C since i posted the edit video and it works!

watching how o+c took code, the screen flashed immediately on.. so I'm thinking now that the screen isn't getting power or signal.. i tried swapping screens with the working one in the oc but it doest work. :(

Ill try swapping out the working teensy as well, but im almost positive it's a power/signal to screen issue now

edit update: yep, this didn't work.. I'm debating at this point reordering all the parts since this was my first SMD build and it honestly came out terrible.
nevetsokyeron
dusk wrote:

Ill try swapping out the working teensy as well, but im almost positive it's a power/signal to screen issue now

edit update: yep, this didn't work.. I'm debating at this point reordering all the parts since this was my first SMD build and it honestly came out terrible.


The display will not show anything if there's no proper firmware on the teensy. So, if that didn't flash then the display will be blank.

I really suggest reflow-ing all the pins on your teensy first thing. Then try to program the teensy while not attached to the main board.

FWIW - You can test voltage to the display pretty easy with your meter - VCC and GND pins are marked on the top of board.
dusk
nevetsokyeron wrote:
dusk wrote:

Ill try swapping out the working teensy as well, but im almost positive it's a power/signal to screen issue now

edit update: yep, this didn't work.. I'm debating at this point reordering all the parts since this was my first SMD build and it honestly came out terrible.


The display will not show anything if there's no proper firmware on the teensy. So, if that didn't flash then the display will be blank.

I really suggest reflow-ing all the pins on your teensy first thing. Then try to program the teensy while not attached to the main board.

FWIW - You can test voltage to the display pretty easy with your meter - VCC and GND pins are marked on the top of board.



that's the thing, I think the software did load on there, but I just can't see anything. I built the o+c today and the loading process was the same, except the TU screen never fired up (I swapped screens, nothing).

i just tried checking the voltage and see -0.09v from GND/VCC on my display.. both on the board and on the OLED

also I cut the lead so I can't use usb power.. unless I soldered a little wire across temporarily...
nevetsokyeron
dusk wrote:

i just tried checking the voltage and see -0.09v from GND/VCC on my display.. both on the board and on the OLED

also I cut the lead so I can't use usb power.. unless I soldered a little wire across temporarily...


Well that's not good. It should be 3.3v

So - you're not getting enough power to the display. I'm pretty sure this 3.3v is coming from the Teensy. See here: 3rd pin away from the USB on the top is 3.3v



Take the Teensy from the O_C and put it in the TempsUtile and try to flash it with the TU firmware. If this works, then the problem is with the other Teensy.
dusk
tried both teensys with the same outcome :(
nevetsokyeron
Looking at the PCB files I see the 78L33 is supplying 3.3v to the display.

Check that for:
1) being the correct component.
2) dry sockets or bad soldering.

also check that 100n cap and 470n cap near the display header.

(EDIT - can't see that area in your pictures, so hard to know whats up visually)
mxmxmx
dusk wrote:
tried both teensys with the same outcome :(


mmh, so i send you another board, ok?
dusk
mxmxmx wrote:
dusk wrote:
tried both teensys with the same outcome :(


mmh, so i send you another board, ok?


ok! I'm stubborn and still going to fight with the temps to debug it.. worst case scenario is I build a few of them

nevetsokyeron wrote:
Looking at the PCB files I see the 78L33 is supplying 3.3v to the display.

Check that for:
1) being the correct component.
2) dry sockets or bad soldering.

also check that 100n cap and 470n cap near the display header.

(EDIT - can't see that area in your pictures, so hard to know whats up visually)


thanks for slogging through this with me nevet, I'll give this a try when I get home from work tonight.

edit - heh, couldnt resist resoldering the 100n and 470n caps.. still same crappy voltage...
nevetsokyeron
dusk wrote:

thanks for slogging through this with me nevet, I'll give this a try when I get home from work tonight.

edit - heh, couldnt resist resoldering the 100n and 470n caps.. still same crappy voltage...


I'd probably try removing and replacing the 78L33.

You should be able to check voltage on that first - should be 5v in (from the Teensy Vin) on one side and 3.3v out (on the pin closest to the edge of the PCB).

FWIW - I had a Turing Machine build last week where I used the wrong voltage regulator and it took me hours and hours to figure out that was the problem. very frustrating
dusk
nevetsokyeron wrote:
dusk wrote:

thanks for slogging through this with me nevet, I'll give this a try when I get home from work tonight.

edit - heh, couldnt resist resoldering the 100n and 470n caps.. still same crappy voltage...


I'd probably try removing and replacing the 78L33.

You should be able to check voltage on that first - should be 5v in (from the Teensy Vin) on one side and 3.3v out (on the pin closest to the edge of the PCB).

FWIW - I had a Turing Machine build last week where I used the wrong voltage regulator and it took me hours and hours to figure out that was the problem. very frustrating


I'll do this tonight and edit this post when I do! if that doesn't work (as in, the voltage reads correctly, what else should I try?)

I'm new to debugging these things (well, new to building them too, this was my first SMD build... first modular build, too actually), but figure a good handle on debugging will be helpful. I plan on building another one of these and o+c to have 2 each in my system. smile
dusk
nevetsokyeron wrote:
dusk wrote:

thanks for slogging through this with me nevet, I'll give this a try when I get home from work tonight.

edit - heh, couldnt resist resoldering the 100n and 470n caps.. still same crappy voltage...


I'd probably try removing and replacing the 78L33.

You should be able to check voltage on that first - should be 5v in (from the Teensy Vin) on one side and 3.3v out (on the pin closest to the edge of the PCB).

FWIW - I had a Turing Machine build last week where I used the wrong voltage regulator and it took me hours and hours to figure out that was the problem. very frustrating


I'll do this tonight and edit this post when I do! if that doesn't work (as in, the voltage reads correctly, what else should I try?)

I'm new to debugging these things (well, new to building them too, this was my first SMD build... first modular build, too actually), but figure a good handle on debugging will be helpful. I plan on building another one of these and o+c to have 2 each in my system. smile
mxmxmx
dusk wrote:

I'm new to debugging these things (well, new to building them too, this was my first SMD build... first modular build, too actually), but figure a good handle on debugging will be helpful. I plan on building another one of these and o+c to have 2 each in my system. :)


first thing i'd do is reflow everything, including the teensy pins, as nevetsokyeron pointed out above. then make sure all the voltages are correct: 5V at the LM1117; 3v3 from teensy (that's mainly feeding the MCP6004, pin 4); 3v3 from the 78L33; -5V from the LM4040. that's it, basically. it's fairly simple, much simpler than O+C; i don't know why your teensy would reboot constantly, ie if your 5V rail is ok.


in other news / fwiw / fyi, there's a PCB version 1c now:



... as i was asked to widen the holes for the encoder lugs, which is what's new in 1c.
dusk
mxmxmx wrote:
dusk wrote:

I'm new to debugging these things (well, new to building them too, this was my first SMD build... first modular build, too actually), but figure a good handle on debugging will be helpful. I plan on building another one of these and o+c to have 2 each in my system. smile


first thing i'd do is reflow everything, including the teensy pins, as nevetsokyeron pointed out above. then make sure all the voltages are correct: 5V at the LM1117; 3v3 from teensy (that's mainly feeding the MCP6004, pin 4); 3v3 from the 78L33; -5V from the LM4040. that's it, basically. it's fairly simple, much simpler than O+C; i don't know why your teensy would reboot constantly, ie if your 5V rail is ok.


in other news / fwiw / fyi, there's a PCB version 1c now:



... as i was asked to widen the holes for the encoder lugs, which is what's new in 1c.


cool! I've give all these things a shot when I get home. I have a funny feeling I nuked the board soldering (I popped a few leads from over soldering.. learned my lesson) - if this doesn't work I'll just wait for new parts and build another one (or two).

will my new order be these new c models? smile

thanks again for your help and putting this project together mx! it's been really fun getting into yet another rabbit hole in this endless hobby. I really enjoy soldering!
nevetsokyeron
mxmxmx wrote:

in other news / fwiw / fyi, there's a PCB version 1c now:

... as i was asked to widen the holes for the encoder lugs, which is what's new in 1c.


Yay! No more filing down my encoder lugs!

Or not (just yet)... as I've still got a handful of 1b PCBs eek!
strange tales
Alright finally got my panel in so I could solder the jacks, turned it on and everything works, but my screen is ridiculously off center from a vertical aspect. The center display only does horizontal. I know this screen works for sure, because I tried it out in my O_C and it works just fine there, but no idea what is causing this.

http://i.imgur.com/l7kCbf8.jpg
shiftr
I building this right now and i just noticed i soldered in 470n 16V in stead of 25V.
What will happen with to low voltage caps? Could i try if it will work anyway or should i replace them to prevent any damage?
mxmxmx
strange tales wrote:
Alright finally got my panel in so I could solder the jacks, turned it on and everything works, but my screen is ridiculously off center from a vertical aspect. The center display only does horizontal. I know this screen works for sure, because I tried it out in my O_C and it works just fine there, but no idea what is causing this.

http://i.imgur.com/l7kCbf8.jpg


mmh, that's odd. it's the same code (ported from OC), just using different pins, so shouldn't make a difference.

shiftr wrote:
I building this right now and i just noticed i soldered in 470n 16V in stead of 25V.
What will happen with to low voltage caps? Could i try if it will work anyway or should i replace them to prevent any damage?


it's probably not ideal, but you'll be fine. there's still some margin and the effective capacitance isn't particularly critical. (two of them sit on the 12V rail (the 45° one right next to the LM4040, and the one next to the LM1117), which is why the BOM specs 25V (> 2x seems to be a/the common derating rule-of-thumb).)
Sinamsis
Does anyone have a compiled version of the most recent firmware for the TU? Basically, I bought one from someone here several months ago. I tried to update it myself, and I think I did so successfully, but I must have compiled from a different branch or whatever. My TU still freezes up frequently when turning the knobs too rapidly. I purchased one from Raph and it works great. I assume (hope) this is just a firmware issue on my older TU and with the right firmware I can fix it.

Also, as an aside, any word on implementing CV control on mults/div? That's the big thing I'm missing from selling my QCD. Thanks in advance!
sockmonkey
Sinamsis wrote:
Does anyone have a compiled version of the most recent firmware for the TU? Basically, I bought one from someone here several months ago. I tried to update it myself, and I think I did so successfully, but I must have compiled from a different branch or whatever. My TU still freezes up frequently when turning the knobs too rapidly. I purchased one from Raph and it works great. I assume (hope) this is just a firmware issue on my older TU and with the right firmware I can fix it.


Attached.
Sinamsis
sockmonkey
You da bomb, thanks so much.
mxmxmx
thanks, jeremy ... was just going to post it.

re:

Sinamsis wrote:

Also, as an aside, any word on implementing CV control on mults/div? That's the big thing I'm missing from selling my QCD. Thanks in advance!


there's been CV control for a good while now (over mult/div and mostly every other parameter). see here

as for freezing up, let me know if that fixes it for you; i haven't had it freeze up.
Sinamsis
mxmxmx wrote:
thanks, jeremy ... was just going to post it.

re:

Sinamsis wrote:

Also, as an aside, any word on implementing CV control on mults/div? That's the big thing I'm missing from selling my QCD. Thanks in advance!


there's been CV control for a good while now (over mult/div and mostly every other parameter). see here

as for freezing up, let me know if that fixes it for you; i haven't had it freeze up.


That's what I thought. I think both my units are running older firmware. Ha it's hard to keep up (that's a good thing). I'm hoping the firmware update will fix the freezing. That has been mentioned by other folks right? Or did I make that up.

I'm always nervous to post here because I'm DIY challenged and have relied on the kindness of strangers to build these awesome modules. I'll try to do the update today and get back to you.
Sinamsis
Holy shit man. I just opened that link. I've been looking for this file forever. The analogous one for the O and C is fantastic. Thanks so much. As a kind of aside, would it maybe be helpful to have a separate thread dedicated just to the firmware of the OC and TU? I'm not trying to be a smart ass or anything. It's just these modules have expanded well beyond DIY it seems. And for numb skulls like me it's a little difficult to sift through the build issues and troubleshooting looking for just a simple software answer. Again, maybe this is inappropriate. Just thought I'd ask.
mxmxmx
Sinamsis wrote:
I'm hoping the firmware update will fix the freezing. That has been mentioned by other folks right? Or did I make that up.


don't know. there was an issue with the 'app select' menu, which would be prone to crash owing to the lack of apps, but that's been fixed. other than that, i haven't heard of things freezing ... which isn't to say it couldn't happen.

Sinamsis wrote:
Holy shit man. I just opened that link. I've been looking for this file forever. The analogous one for the O and C is fantastic. Thanks so much. As a kind of aside, would it maybe be helpful to have a separate thread dedicated just to the firmware of the OC and TU? I'm not trying to be a smart ass or anything. It's just these modules have expanded well beyond DIY it seems. And for numb skulls like me it's a little difficult to sift through the build issues and troubleshooting looking for just a simple software answer. Again, maybe this is inappropriate. Just thought I'd ask.


yeah, it kind of makes sense in theory, but separate threads don't really seem to work in practice; there used to be two OC threads, we had one locked eventually because it didn't work/ended up being more confusing. fwiw, there's a less busy OC thread in the main eurorack forum, so that would be an option.
Sinamsis
Ok, so I'm not sure if I'm updating the firmware correctly. I ended up just downloading the master folder off of github. I compiled it correctly I think (I opened up the ino file in the Arduino app, clicked upload, it said compiling, then done uploading and then the module resets. Is that all I should expect? Is there a way to confirm the right firmware is uploaded? Thanks for bearing with me. I'm really clueless with this stuff.

And now that you mentioned the app select menu, I understand what you mean. Yes, I see 6 clocks and then it bricks. Haha. Very rarely. I must be holding the right encoder down for too long and I enter the app select menu. It all makes sense now.
mxmxmx
Sinamsis wrote:
Ok, so I'm not sure if I'm updating the firmware correctly. I ended up just downloading the master folder off of github. I compiled it correctly I think (I opened up the ino file in the Arduino app, clicked upload, it said compiling, then done uploading and then the module resets. Is that all I should expect? Is there a way to confirm the right firmware is uploaded? Thanks for bearing with me. I'm really clueless with this stuff.


basically yes. there's a little window/progress bar which should say something along the lines of "programming", "reboot", and "ok". that's it. fwiw, here's a [url=https://github.com/mxmxmx/temps_utile-/wiki/firmware ]how to[/url]. depending on the version of arduino/teensyduino you have, you can skip step 3).

anyways, given you had some older version of the firmware running, an easy way to tell is: you should now be able assign the CV inputs to the various parameters (?)

Sinamsis wrote:

And now that you mentioned the app select menu, I understand what you mean. Yes, I see 6 clocks and then it bricks. Haha. Very rarely. I must be holding the right encoder down for too long and I enter the app select menu. It all makes sense now.


mmh, i can't seem to reproduce this.
Sinamsis
I followed those instructions. I just wasn't sure if I would see some confirmation. I think I did it right. And yes I can't assign CVs now (!!!!!). This thing is awesome!

I'll mess with it some more and see if I can duplicate the freezing (hopefully I can't). Yesterday it was working ok.

In general, the last time I looked at the "manual" file that you just posted it was just a picture of the panel with a brief explanation of what the knobs did. And the up and down buttons did not have that functionality. Reading the updated version has helped a lot. Part of my confusion was coming from trying to treat the TU like the OC when the layout is actually different. Thanks for bearing with me!
Sinamsis
So it seems updating the firmware worked. No more freezing.... I have to say, what a f'ing awesome module! CV'ing the mult/div and combining it with other clocks into a logic module like the Plog is fantastic. I'm glad I have two of these haha.

Out of curiosity would it be possible to put in a virtual attenuator (or attenuverter) on the software side for incoming CV? So basically you define a percentage of the incoming voltage that will affect divisions or multiplications? Ha forgive me if that's a stupid question.
nevetsokyeron
Sinamsis wrote:

And now that you mentioned the app select menu, I understand what you mean. Yes, I see 6 clocks and then it bricks. Haha. Very rarely. I must be holding the right encoder down for too long and I enter the app select menu. It all makes sense now.


This *could* be the display pins causing a freeze/reboot?

Two tricks here to be sure the display is not shorting out on the panel:

1) trim the pins on the top side of the display.
2) electrical tape on the inside of the panel to insulate the display pins from touching the panel.
heapish
Hey, building a yellow pcb. I asked you a bunch of stuff earlier in the thread.
Finally getting through my backlog. The pcb has meant to have come from you via a 3rd party.
I've been using https://github.com/mxmxmx/temps_utile-/wiki/yellow-boards to guide me through but some things dont tie up.

On the board there are bits not shown on the page above. I've included a picture. It seems to be a mix of v0 and v1.

Circled there is places for 500R as well as on the other side, newer versions have 510R....I have 510R resistors, is it ok to use them?

Also there is positions for 0.1, but 0.1 what? Same again with 0.33?

Whats the connector on the right?

Is CV-IN a TL074 or MCP6004 (Just checking as for some reason i ordered 3 TL074 and no MCP6004)

(I missed ordering 1k resistors doh)

Cheers smile
mxmxmx
heapish wrote:

Circled there is places for 500R as well as on the other side, newer versions have 510R....I have 510R resistors, is it ok to use them?


500R was a typo. 510R is the common value, so yes.

Quote:

Also there is positions for 0.1, but 0.1 what? Same again with 0.33?


0.1uF, 0.33uF

Quote:

Whats the connector on the right?


the three-pin thing? -- 7805

Quote:

Is CV-IN a TL074 or MCP6004 (Just checking as for some reason i ordered 3 TL074 and no MCP6004)


TL074

Quote:

(I missed ordering 1k resistors doh)


that's just the series output resistors. 510R will be fine, too.
mxmxmx
Sinamsis wrote:

Out of curiosity would it be possible to put in a virtual attenuator (or attenuverter) on the software side for incoming CV? So basically you define a percentage of the incoming voltage that will affect divisions or multiplications? Ha forgive me if that's a stupid question.


not a stupid question, it has come up before ... sure, would be possible. it's mainly an UI question (how best to implement it), and a question of time (when to implement it...)
heapish
Thank you. Sorry its not 3. I mean the connector bit. I've taken a picture. Next to the 0.33uf.
mxmxmx
heapish wrote:
Thank you. Sorry its not 3. I mean the connector bit. I've taken a picture. Next to the 0.33uf.


the three big holes with the square silkscreen around them is for the 7805. the two small ones on top you could use for a 2.5mm cap, say 100n, but that's optional because there's another cap downstream / onboard the teensy.

or see here, i found an old picture.
heapish
mxmxmx wrote:
heapish wrote:
Thank you. Sorry its not 3. I mean the connector bit. I've taken a picture. Next to the 0.33uf.


the three big holes with the square silkscreen around them is for the 7805. the two small ones on top you could use for a 2.5mm cap, say 100n, but that's optional because there's another cap downstream / onboard the teensy.

or see here, i found an old picture.

Thankyou. Missing that too. Got a spare 100n cap so I'll put it in.
Sinamsis
mxmxmx wrote:
Sinamsis wrote:

Out of curiosity would it be possible to put in a virtual attenuator (or attenuverter) on the software side for incoming CV? So basically you define a percentage of the incoming voltage that will affect divisions or multiplications? Ha forgive me if that's a stupid question.


not a stupid question, it has come up before ... sure, would be possible. it's mainly an UI question (how best to implement it), and a question of time (when to implement it...)


Nice, you guys have already come a long ways! Just thinking of ways to put the icing on the cake.... I actually just ordered my third O and C, and I have 2 TU (one for each case). It's really changed the way I patch. I wish the O and C could have an app per channel like the TU does. It's allowed me to get rid of several modules.
strange tales
What resistors/capacitors are connected to the screen? I'm being lazy and asking here because I won't be able to check for a couple days.

My screen will usually be normal instead of that vertical-off positioning on boot, like 80/20 chance with 80 being normal, but sometimes it flickers to the vertical-off and goes back to normal all at random.
mxmxmx
strange tales wrote:
What resistors/capacitors are connected to the screen? I'm being lazy and asking here because I won't be able to check for a couple days.

My screen will usually be normal instead of that vertical-off positioning on boot, like 80/20 chance with 80 being normal, but sometimes it flickers to the vertical-off and goes back to normal all at random.


none. connections go straight from the MCU to the OLED. check the OC schematic, same principle. it's 4 wire / SPI and some extra signals; the only caps would be around the 78L33.
diablojoy
Hi mxmxmx
just wondering if you had any boards available still ?
mxmxmx
diablojoy wrote:
Hi mxmxmx
just wondering if you had any boards available still ?


not right now, i'll get a few more in ~ 2 weeks.
diablojoy
Awesome
thanks!
Altitude909
If anyone in the US is looking for boards, I have more than I need. $10 shipped, drop me a PM
heapish
Back again, just want to confirm what im doing. Not sure what you mean to do when saying "Comment out" does this mean to take out the //?

I've done a screenshot and found the line in question (I'm yellow board)

"NB: when compiling the firmware for the older/yellow PCB version (the one with a TL074), you have to comment out the line that says #define _TEMPS_UTILE_REV (in TU_gpio.h)."

Cheers smile
m0d
"Comment out" essentially means adding // to the beginning of a line. The line in your screenshot is already commented out.
mxmxmx
heapish wrote:

"NB: when compiling the firmware for the older/yellow PCB version (the one with a TL074), you have to comment out the line that says #define _TEMPS_UTILE_REV (in TU_gpio.h)."


sorry, my bad. i had changed the code but not the instructions (fixed now). comment out is to add '//' , as m0d says. what you want to do is uncomment that line, ie remove the '//'.
heapish
Right cool. Remove the //
Rolling.
webboy
Just finished a TU, seems to be mostly working. Have not calibrated it yet though.

For some reason, when twisting the right encoder counter-clockwise it seems to glitch out and jump to the app menu. I am positive I am not pressing down.

I'm running the latest commit - I also tried the previous commit and the latest pre-compiled hex from above in this thread. I've come to the conclusion that I need to replace the encoder and / or reflow a bunch of stuff. FWIW the encoders are from aliexpress and turn correctly without modding the firmware. I have two on a perfectly working O_c, so I think in general they are ok.

I have a rev 1 board which I didn't purchase from Max - so there that is.

I cleaned the board with 100% iso alcohol and an ESD brush up until I soldered the encoders, switches and jacks. I suppose cleaning the flux from the last components would be a good idea as well...

Any help appreciated.
webboy
Well that was easy - it was the flux. I'll just leave this here as a cautionary tale. confused Love those easy fixes though.

webboy wrote:
Just finished a TU, seems to be mostly working. Have not calibrated it yet though.

For some reason, when twisting the right encoder counter-clockwise it seems to glitch out and jump to the app menu. I am positive I am not pressing down.

I'm running the latest commit - I also tried the previous commit and the latest pre-compiled hex from above in this thread. I've come to the conclusion that I need to replace the encoder and / or reflow a bunch of stuff. FWIW the encoders are from aliexpress and turn correctly without modding the firmware. I have two on a perfectly working O_c, so I think in general they are ok.

I have a rev 1 board which I didn't purchase from Max - so there that is.

I cleaned the board with 100% iso alcohol and an ESD brush up until I soldered the encoders, switches and jacks. I suppose cleaning the flux from the last components would be a good idea as well...

Any help appreciated.
webboy
I've been messing around a bit - a few questions-

Am I correct in assuming that the 100n cap behind the right encoder is there for debounce purposes? My problem of ghost clicking returned, so I removed the cap for troubleshooting and I no longer seem to have a problem.

There seems to be no start / stop functionality when running on the internal clock, correct?

When I have all channels in MULT mode and set to clock source TR1 with no incoming clock- it seems like any channel that is set to multiply continues to run - is that expected behaviour? ( Conversely, this doesn't happen when a channel is set to divide.)

Thanks.
toneburst
webboy wrote:
When I have all channels in MULT mode and set to clock source TR1 with no incoming clock- it seems like any channel that is set to multiply continues to run - is that expected behaviour? ( Conversely, this doesn't happen when a channel is set to divide.)


Slightly confusingly, clock multiplication actually works by measuring the time between incoming clock pulses, then dividing that time, and producing new pulses based on this division. This explains why it continues when the external clock stops. It simply keeps producing pulses based on a division of the time between the last two incoming pulses, whenever they happened.

Clock division, on the other hand, simply counts incoming pulses, and produces a new pulse every x external clock pulses. It can't count pulses when they stop coming in, so it stops producing any output.

In other words; yes, that's expected behaviour.

a|x
mxmxmx
webboy wrote:
I've been messing around a bit - a few questions-

Am I correct in assuming that the 100n cap behind the right encoder is there for debounce purposes? My problem of ghost clicking returned, so I removed the cap for troubleshooting and I no longer seem to have a problem.


yep, not sure why it would produce ghost clicks, but if it works better without, just leave it off. it's not essential.

webboy wrote:

There seems to be no start / stop functionality when running on the internal clock, correct?


correct ... there's just two buttons, etc. i suppose though it could be crammed in somehow.

webboy wrote:

When I have all channels in MULT mode and set to clock source TR1 with no incoming clock- it seems like any channel that is set to multiply continues to run - is that expected behaviour? ( Conversely, this doesn't happen when a channel is set to divide.)


as toneburst says, it because of the way clock multiplication works. same thing with eg. 4ms SCM. there's no circuitry to detect if/when the cable has been removed, so there's no way telling that multiplication should stop.
webboy
Thanks for the answers gents. smile
Sammus
So I just building mine, and noticed I'd done a few subs of the capacitors when I was ordering for stock levels. Somehow I managed to mismatch the tolerances of the recommended part numbers on the github BOM, and I don't have the knowledge to understand if it matters for these:

1) for the 2x 1n caps, BOM is 5%, mine is 10% (both C0G/NP0)
2) 5x 470n, BOM is X7R 5%, mine is 10% (not sure of the dielectric - the "samsung" ones from Tayda whose part number I've realise is an impossible combination of letters - all the tayda smd caps are apparently C0G/NP0, even the once with capacitance well beyond what is possible according to wiki)
3) for the 2x 1u, bom X7R 10%, mine is Y5V -20% + 80 %. This is obviously the biggest difference - and I've made the same subs for the O_C.

Will everything still work OK, or should I get some other caps with tigheter tolerances?
mxmxmx
Sammus wrote:


Will everything still work OK, or should I get some other caps with tighter tolerances?


that'll all be fine. the tolerances aren't all that important; the voltage rating is more relevant, they should be > 25V
blip
Speaking about those 470n capacitors, the bom part suggestion is this one : 77-VJ0805Y474JXJTBC
While sorting out components from my mouser order I found out it is rated 16V, not 25.
Did anyone already built the module successfully with this part, or should I wait and order new caps ?
mxmxmx
blip wrote:
Speaking about those 470n capacitors, the bom part suggestion is this one : 77-VJ0805Y474JXJTBC
While sorting out components from my mouser order I found out it is rated 16V, not 25.
Did anyone already built the module successfully with this part, or should I wait and order new caps ?


sorry, my bad, fixed. it'll be ok to use 16V. there's actually just two of them sitting on the 12V bus, where 25V+ would be more suitable (the 45° one next to the LM4040-5, and one right next to the LM1117. if you have any spares, you could use 100n instead. they're not critical).
blip
Thanks for your quick answer Max.
I have plenty of 100n so i will use them instead.
heapish
Hopefully last time.... Yellow board. Bom says 7x 1k resistors....
I can only see 6 spaces
mxmxmx
heapish wrote:
Hopefully last time.... Yellow board. Bom says 7x 1k resistors....
I can only see 6 spaces


the BOM / 7 is for the more recent boards.
nevetsokyeron
mxmxmx wrote:
blip wrote:
Speaking about those 470n capacitors, the bom part suggestion is this one : 77-VJ0805Y474JXJTBC
While sorting out components from my mouser order I found out it is rated 16V, not 25.
Did anyone already built the module successfully with this part, or should I wait and order new caps ?


sorry, my bad, fixed. it'll be ok to use 16V. there's actually just two of them sitting on the 12V bus, where 25V+ would be more suitable (the 45° one next to the LM4040-5, and one right next to the LM1117. if you have any spares, you could use 100n instead. they're not critical).


I think that 470n part number was lifted from the O+C BOM - which might also need to be updated.

Alternate mouser part here: 603-CC805KKX7R8BB474
(Yageo Multilayer Ceramic Capacitors MLCC - SMD/SMT 470nF 25V X7R 10%)

Max changed the BOM to this one (50v)
603-CC805ZRY5V9BB474
mxmxmx
nevetsokyeron wrote:

I think that 470n part number was lifted from the O+C BOM - which might also need to be updated.


yep, that was just copy+paste. the 16V ones are ok for O+C.

... also updated a couple of other parts, because those were out of stock.
heapish
mxmxmx wrote:
heapish wrote:
Hopefully last time.... Yellow board. Bom says 7x 1k resistors....
I can only see 6 spaces


the BOM / 7 is for the more recent boards.

Cool. It turns on anyway! Thanks for all your help.
Just need to calibrate it when I've recovered from my hangover.
heapish
Just calibrated this and 2 oc.
Sadly the Temps isn't outputting on E and F. But everything else seems to be working and reacting.

Ill give everything a reflow when I get chance after Christmas. But in case you see this before I get to it, is there anything I can check or measure?

Have a lovely holiday.
Cheers
mxmxmx
heapish wrote:
Just calibrated this and 2 oc.
Sadly the Temps isn't outputting on E and F. But everything else seems to be working and reacting.


E and F should be an easy fix — take a look at the passives surrounding pins 12, 13, and 14 (TL074), ie both: E is going through the one on the right, F through the one on the left. (details here.)


heapish wrote:

Have a lovely holiday.
Cheers


cheers. same to you
Sammus
Got my two up and running! everything seems to be in order, except one of them doesnt power up all the time. I can have nothing else hooked up, tried both elby power and a tiptop studio bus. All voltages check out, the led on the teensy lights up. Any ideas?
mxmxmx
Sammus wrote:
Got my two up and running! everything seems to be in order, except one of them doesnt power up all the time.


mmh, that's odd that it should be only one of them. can you measure the current consumption of the one that's not starting up properly? it shouldn't exceed 80mA or so on the +12V rail.
heapish
mxmxmx wrote:
heapish wrote:
Just calibrated this and 2 oc.
Sadly the Temps isn't outputting on E and F. But everything else seems to be working and reacting.


E and F should be an easy fix — take a look at the passives surrounding pins 12, 13, and 14 (TL074), ie both: E is going through the one on the right, F through the one on the left. (details here.)


Yellow board. Reflowed everything. No output still. I have access to oscilloscope, is there a way I can check some points. Say if I set the Temps to pass clock from in to E and F then probe some points? (I've not really used an oscilloscope much, other than to view waveforms)
heapish
I did some measurements but then I plugged it in backwards. Now its dead and the regulator gets hot. Any chance changing the black diodes will bring it back?

Here is what I got from it before I killed it.
Left tl074
1 pulse
7 pulse
8 high
14 pulse

Right
1 pulse
7 nothing
8 nothing
14 high

The E and F outputs measured high.
diablojoy
still looking for a board
mxmxmx any available ?
mxmxmx
heapish wrote:


Yellow board. Reflowed everything. No output still. I have access to oscilloscope, is there a way I can check some points. Say if I set the Temps to pass clock from in to E and F then probe some points? (I've not really used an oscilloscope much, other than to view waveforms)


for those boards, E is pin 2, F is pin 9. see here. they go straight into the non-inverting input (i got it wrong btw, F is using the op amp at pins 8/9/10, left TL074, not 12/13/15).

heapish wrote:
I did some measurements but then I plugged it in backwards. Now its dead and the regulator gets hot. Any chance changing the black diodes will bring it back?


mmh, it actually should survive that kind of thing. anyways, if the regulator gets hot, i don't think things will be ok again just by changing the diodes. shouldn't i just send you a new PCB?

diablojoy wrote:

still looking for a board
mxmxmx any available ?


pm me, i have a few. or alternatively: http://magpie-modular.myshopify.com/products/temps-utile-pcb
Sammus
mxmxmx wrote:
Sammus wrote:
Got my two up and running! everything seems to be in order, except one of them doesnt power up all the time.


mmh, that's odd that it should be only one of them. can you measure the current consumption of the one that's not starting up properly? it shouldn't exceed 80mA or so on the +12V rail.


Wasn't quite sure the best way to do this, so I made up a special power cable with my DMM in the middle of the 12V strands. The TU measures about 35mA when it fails to power up properly, and about 85mA when it powers up normally.

Also noticed I'd forgotten to populate the through hole 470n cap! I was hoping that might have something to do with the power issue, but alas no.
diablojoy
PM sent
thanks
Sammus
Sammus wrote:
mxmxmx wrote:
Sammus wrote:
Got my two up and running! everything seems to be in order, except one of them doesnt power up all the time.


mmh, that's odd that it should be only one of them. can you measure the current consumption of the one that's not starting up properly? it shouldn't exceed 80mA or so on the +12V rail.


Wasn't quite sure the best way to do this, so I made up a special power cable with my DMM in the middle of the 12V strands. The TU measures about 35mA when it fails to power up properly, and about 85mA when it powers up normally.

Also noticed I'd forgotten to populate the through hole 470n cap! I was hoping that might have something to do with the power issue, but alas no.


Further to this, I realised I when I thought I was testing different power supplies, (i.e. TTA studio bus vs elby ED126) I was actually plugging into the the studio bus both times. Using the Elby they seem to power on every go!

Still i'm a little confused, the tiptop studio bus was empty, even with them full up it is running well well below it's rated max.

I just finished building 2x O_C and have exactly the same issue.
heapish
I've pm'd you about a fresh pcb
mxmxmx
Sammus wrote:
Sammus wrote:
mxmxmx wrote:
Sammus wrote:
Got my two up and running! everything seems to be in order, except one of them doesnt power up all the time.


mmh, that's odd that it should be only one of them. can you measure the current consumption of the one that's not starting up properly? it shouldn't exceed 80mA or so on the +12V rail.


Wasn't quite sure the best way to do this, so I made up a special power cable with my DMM in the middle of the 12V strands. The TU measures about 35mA when it fails to power up properly, and about 85mA when it powers up normally.

Also noticed I'd forgotten to populate the through hole 470n cap! I was hoping that might have something to do with the power issue, but alas no.


Further to this, I realised I when I thought I was testing different power supplies, (i.e. TTA studio bus vs elby ED126) I was actually plugging into the the studio bus both times. Using the Elby they seem to power on every go!

Still i'm a little confused, the tiptop studio bus was empty, even with them full up it is running well well below it's rated max.

I just finished building 2x O_C and have exactly the same issue.


looks to be the same issue ... see O_C thread, unfortunately i'm a bit clueless

heapish wrote:
I've pm'd you about a fresh pcb


sorry, still recovering, pm'd you.
flts
FWIW I remember hearing about some Teensy based modules (Orgone Accumulator, possibly Radio Music?) not always starting properly on some PSUs. Maybe the root of the issue is the same? Can't remember what the problem was about, though, but several of my friends have complained something to that effect.

I think Zeus Studio Bus is using a hybrid DC-DC + LDO (?) configuration, includes soft start type circuitry and some kind of overcurrent protection. It possibly has their own DC-DC design as well unless it's something rebranded. So it's a pretty rare (if not unique) combination in euroland in that respect.
Sammus
Not sure if this has anything to do with anything, or is even a problem, but in diagnosing mine I noticed that the analogue outputs of the TU fire out a 12Vpp blip on power on. Is that normal? I've attached scope shots here. The first shot is the whole signal on power on, the second shot is zoomed in on the first spike you can just see.
mxmxmx
Sammus wrote:
Not sure if this has anything to do with anything, or is even a problem, but in diagnosing mine I noticed that the analogue outputs of the TU fire out a 12Vpp blip on power on. Is that normal? I've attached scope shots here. The first shot is the whole signal on power on, the second shot is zoomed in on the first spike you can just see.


mmh, i can't replicate it; it looks a bit weird. here's how it looks here, using a vanilla doepfer PSU; there's a tiny blib of sorts, but nowhere near 12V:






flts wrote:

FWIW I remember hearing about some Teensy based modules (Orgone Accumulator, possibly Radio Music?) not always starting properly on some PSUs. Maybe the root of the issue is the same? Can't remember what the problem was about, though, but several of my friends have complained something to that effect.

I think Zeus Studio Bus is using a hybrid DC-DC + LDO (?) configuration, includes soft start type circuitry and some kind of overcurrent protection. It possibly has their own DC-DC design as well unless it's something rebranded. So it's a pretty rare (if not unique) combination in euroland in that respect.


yeah, i vaguely remember issues with radio music, but in that case i was inclined to think it's due to it being underpowered (100mA for teensy+SD card); the LM1117 on OC/TU i think is 800mA max, which should be plenty. anyways, it seems to be a rare issue. there must be a couple of hundred OCs out in the wild now, and just a very few (known to us, at any rate) instances of power up issues.
Sammus
mxmxmx wrote:
Sammus wrote:
Not sure if this has anything to do with anything, or is even a problem, but in diagnosing mine I noticed that the analogue outputs of the TU fire out a 12Vpp blip on power on. Is that normal? I've attached scope shots here. The first shot is the whole signal on power on, the second shot is zoomed in on the first spike you can just see.


mmh, i can't replicate it; it looks a bit weird. here's how it looks here, using a vanilla doepfer PSU; there's a tiny blib of sorts, but nowhere near 12V:


Are we measuring the same thing? I'm curious as yours does not return to 0V, but stays around 5V. I am measuring from a patch into output A at the moment the unit powers up, we'll before the oled turns on or anything.
mxmxmx
Sammus wrote:

Are we measuring the same thing? I'm curious as yours does not return to 0V, but stays around 5V. I am measuring from a patch into output A at the moment the unit powers up, we'll before the oled turns on or anything.


ah, no, we didn't. i thought we were talking about output D ("analogue output"). here's A:



so yeah, there is a little spike early on during power up; it's unrelated to the OLED, because it's there with or without it. in my case it's more like 2-4V (it varies) and doesn't look quite as jagged:



it doesn't trigger peaks in drum mode, but is enough to fire off an ADSR. not sure what causes this, it must have to do with the output op amps coming up, it's there whatever i do with the output pins (keep them in high-Z, initialise them earlier, or later); anyways, it's unlikely to be related to the start-up issues.
Sammus
mxmxmx wrote:

ah, no, we didn't. i thought we were talking about output D ("analogue output").


Oops, my bad. In my head I keep referring to them backwards in my head because D comes from a DAC. Gotta fix that!

Cheers anyway, when I get a chance I'll see if mine looks any nicer using the Elby power.

Any other ideas on what I else could check to help diagnose? I'm not real experienced at this stuff smile
mxmxmx
Sammus wrote:

Any other ideas on what I else could check to help diagnose? I'm not real experienced at this stuff :)


mmh, well, if you wanted to try a few things out -- i'd be curious if it comes up without the OLED. you could either simply remove it, or try the OC DAC test posted further upthread. another (more tedious) thing to look at would be to look at what happens at the 12V, 5V, and 3v3_D power busses during power up.
Sammus
mxmxmx wrote:
Sammus wrote:
Not sure if this has anything to do with anything, or is even a problem, but in diagnosing mine I noticed that the analogue outputs of the TU fire out a 12Vpp blip on power on. Is that normal? I've attached scope shots here. The first shot is the whole signal on power on, the second shot is zoomed in on the first spike you can just see.


mmh, i can't replicate it; it looks a bit weird. here's how it looks here, using a vanilla doepfer PSU; there's a tiny blib of sorts, but nowhere near 12V:
...


That exact weird pattern turned out to be from my power switch. I have 15vdc coming into the case and had a double pole switch wired to switch + and - and the same time. I've since learned that unless you have a floating negative (mine is earthed) you should only switch the +. Blip gone.

mxmxmx wrote:

mmh, well, if you wanted to try a few things out -- i'd be curious if it comes up without the OLED. you could either simply remove it, or try the OC DAC test posted further upthread. another (more tedious) thing to look at would be to look at what happens at the 12V, 5V, and 3v3_D power busses during power up.


I'll find time to do this in the coming days. What do you mean by 3.3_D?
mxmxmx
Sammus wrote:

I'll find time to do this in the coming days. What do you mean by 3.3_D?


cool. 3v3_D = teensy 3v3 / the onboard regulator (LP38691):



that's what supplies the MK20 chip, so it would be interesting to see what's happening there (pic comes from the OC schematic, but TU is mostly identical). there's a second 3v3 pin at the shorter end of the teensy where you could tap it.
Sammus
mxmxmx wrote:
Sammus wrote:

I'll find time to do this in the coming days. What do you mean by 3.3_D?


cool. 3v3_D = teensy 3v3 / the onboard regulator (LP38691):



that's what supplies the MK20 chip, so it would be interesting to see what's happening there (pic comes from the OC schematic, but TU is mostly identical). there's a second 3v3 pin at the shorter end of the teensy where you could tap it.


So in trying to take measurements of course the one I am connected to starts perfectly over many many power cycles. I have a few scope shots here: http://imgur.com/a/5JRo9

The last one is typical when I power cycle quickly (i.e. maybe 1s or less: I see the TU starting normally, set trigger, switch off then on). Not quite sure why it looks like that, but I guess it has something to do with the power caps retaining maybe some charge or something?

The second last one is strange. It may have been from a fast power cycle, but it doesn't have the charactaristing flat portion. The TU started fine still.

Bad news: I had my other TU and an OC not power up properly several times while connected to my elby power board. First time I've seen it happen in all this, so a rarity to be sure, being the first time in 100+ power cycles. Still worries me.
pld
Sammus wrote:
So in trying to take measurements of course the one I am connected to starts perfectly over many many power cycles. I have a few scope shots here: http://imgur.com/a/5JRo9

The last one is typical when I power cycle quickly (i.e. maybe 1s or less: I see the TU starting normally, set trigger, switch off then on). Not quite sure why it looks like that, but I guess it has something to do with the power caps retaining maybe some charge or something?

Yeah, there's some buffering that will happen, both on module and in PSU.

FWIW I have two OC and a TU connected to a TTA Studio Bus + Cincon and they seem to boot normally every time from cold start (* so far, switching on the DC side). So my first test was off/on cycling as well (QA habits die hard...). One OC (2D + Teensy 3.2) appears to always boot normally, the other (older PCB with 78l33 + Teensy 3.1) almost always fails. The TU (older PCB with 7805 & 78l33, old firmware, Teensy 3.1) seems somewhere in between, but subjectively boots more often than it fails. Throwing 2 Braids (that happened to be lying around) on the Bus appears to increase the failure rate of the older OC.

It was just a quick test until I can get some measurements myself, and there's too many variables in the mix, but maybe a relevant question is 3.1 (smaller vreg footprint) or 3.2?
Sammus
Sammus wrote:
...I have a few scope shots here: http://imgur.com/a/5JRo9


I got some of the OC not power up properly. Unfortunately nothing looks odd, they OC start and fail shots look almost identical - the failed start has the power busses get to max voltage a little sooner. There is a small blip early on in the fail shot, but that is from the switch contacts - a few other fail shots I had didn't get it.

With all this power cycling I did notice again, several failed starts on the elby power board :(
Sammus
pld wrote:
Sammus wrote:
So in trying to take measurements of course the one I am connected to starts perfectly over many many power cycles. I have a few scope shots here: http://imgur.com/a/5JRo9

The last one is typical when I power cycle quickly (i.e. maybe 1s or less: I see the TU starting normally, set trigger, switch off then on). Not quite sure why it looks like that, but I guess it has something to do with the power caps retaining maybe some charge or something?

Yeah, there's some buffering that will happen, both on module and in PSU.

FWIW I have two OC and a TU connected to a TTA Studio Bus + Cincon and they seem to boot normally every time from cold start (* so far, switching on the DC side). So my first test was off/on cycling as well (QA habits die hard...). One OC (2D + Teensy 3.2) appears to always boot normally, the other (older PCB with 78l33 + Teensy 3.1) almost always fails. The TU (older PCB with 7805 & 78l33, old firmware, Teensy 3.1) seems somewhere in between, but subjectively boots more often than it fails. Throwing 2 Braids (that happened to be lying around) on the Bus appears to increase the failure rate of the older OC.

It was just a quick test until I can get some measurements myself, and there's too many variables in the mix, but maybe a relevant question is 3.1 (smaller vreg footprint) or 3.2?


All Teensy 3.2, the O_C are the latest PCB (2e) and the TU are the first rev 1b (02/2016).

I haven't noticed any correlation with bad starts and power cycling. Obviously the number of cold starts is far far smaller, but I'm pretty sure I've had failure on a cold start before. But with so much testing going on lately it's hard to remember. I'll certainly keep it in mind from now on.

I also feel like when I plug a couple of them in to the same bus the failure rate increases, but I can't be sure. The other maybe feeling which I don't have enough data on is that it may just be 2 of the builds (ie one TU and one OC). Today I noticed the one I picked to test never failed, then I got fed up and swapped all my probes to the one of the O_Cs I saw fail and got some failures to measure soon after.
Sammus
Oops - double post.
mxmxmx
Sammus wrote:


All Teensy 3.2, the O_C are the latest PCB (2e) and the TU are the first rev 1b (02/2016).

I haven't noticed any correlation with bad starts and power cycling. Obviously the number of cold starts is far far smaller, but I'm pretty sure I've had failure on a cold start before. But with so much testing going on lately it's hard to remember. I'll certainly keep it in mind from now on.

I also feel like when I plug a couple of them in to the same bus the failure rate increases, but I can't be sure. The other maybe feeling which I don't have enough data on is that it may just be 2 of the builds (ie one TU and one OC). Today I noticed the one I picked to test never failed, then I got fed up and swapped all my probes to the one of the O_Cs I saw fail and got some failures to measure soon after.


mmh, not sure what to make of this either, i'm afraid. the failures don't look particular suspicious.
bemerritt
Finished up my Temps and loving it. In this video I have the divisors set to 1, 2, 4, 8, 16, and 32.

I am trying to get them in sync by pushing the left encoder, is this correct?

Also having a hell of a time resetting them, am i missing something simple?

Thanks for the help!



Edited to say that if I save the state and then power cycle, it comes on in time
mxmxmx
bemerritt wrote:
Finished up my Temps and loving it. In this video I have the divisors set to 1, 2, 4, 8, 16, and 32.

I am trying to get them in sync by pushing the left encoder, is this correct?

Also having a hell of a time resetting them, am i missing something simple?


yep, though i forgot implementing 'sync' for the internal clock. i've just pushed a fix, ... works now?

generally speaking though, the behaviour will somewhat diverge from a regular clock divider; it's 6 independent channels rather than 1 channel with several outputs.
bemerritt
mxmxmx wrote:
bemerritt wrote:
Finished up my Temps and loving it. In this video I have the divisors set to 1, 2, 4, 8, 16, and 32.

I am trying to get them in sync by pushing the left encoder, is this correct?

Also having a hell of a time resetting them, am i missing something simple?


yep, though i forgot implementing 'sync' for the internal clock. i've just pushed a fix, ... works now?

generally speaking though, the behaviour will somewhat diverge from a regular clock divider; it's 6 independent channels rather than 1 channel with several outputs.


Thanks! After looking thru the whole thread it makes more sense. I do like the Idea about them being independent until being told to sync, very similar to the tempi in that regard.

Overall this thing is a beast and I encourage anyone on the fence to build it. I have never had a Pams, but it blows the QCD and Tempi out of the water in terms of clock duties.
nevetsokyeron
mxmxmx wrote:

yep, though i forgot implementing 'sync' for the internal clock. i've just pushed a fix, ... works now?


This appears to be working properly now.

Query/observation - (on INT clock) When changing mult/div values -- if I set to a long div like /48 or /64 and then change back to a shorter one like /2 or just 1/1 - it looks like that channel has to complete it's current "cycle" at the long setting before changing back to the new div setting.

is that the expected behavior? Or should it immediately reset to the new div amount?
mxmxmx
nevetsokyeron wrote:


Query/observation - (on INT clock) When changing mult/div values -- if I set to a long div like /48 or /64 and then change back to a shorter one like /2 or just 1/1 - it looks like that channel has to complete it's current "cycle" at the long setting before changing back to the new div setting.

is that the expected behavior? Or should it immediately reset to the new div amount?


yeah, that's how it works at the moment, in both modes. if you wanted to force it use the new value, you'd have to reset the divisor value, here/like so.

not sure which one is more desirable, the response to CV or manual adjustment is somewhat different, obviously. a/the alternative would be to do something like: div_cnt_ -= divisors_[_multiplier];, which should result in more gentle changes.

edit. ... i've just compared the three options and some variations on the substraction, and when CV-ing the divisor/multiplier i think the behaviour as is (= wait to complete) tends to sound best. there might be other options, but it's probably ok as is.
nevetsokyeron
I just built up 2 temps and I'm seeing something on both that I've not encounter before (on temps or O_C).

If I turn either encoder really fast I see a brief flash of the "dots" (BPM screen) once or twice. Like it just blinks in/out ever so slightly.

I checked one of my older temps and it does not do this (all running the most recent master firmware).

Any thoughts on what might be causing that?
mxmxmx
nevetsokyeron wrote:
I just built up 2 temps and I'm seeing something on both that I've not encounter before (on temps or O_C).

If I turn either encoder really fast I see a brief flash of the "dots" (BPM screen) once or twice. Like it just blinks in/out ever so slightly.

I checked one of my older temps and it does not do this (all running the most recent master firmware).

Any thoughts on what might be causing that?


the screensaver page is set when pressing the "up" button, so it almost sounds as if pin 3 is pulled low, for some reason, when turning the encoders. i don't know why this would be an issue here but not on o_C or your older builds, it works the same for all of them (in terms of hardware. screensaver needs long-press on o_C); to check whether that's indeed happening, can you comment out line #1942-#1945 in APP_CLK?
nevetsokyeron
mxmxmx wrote:

the screensaver page is set when pressing the "up" button, so it almost sounds as if pin 3 is pulled low, for some reason, when turning the encoders. i don't know why this would be an issue here but not on o_C or your older builds, it works the same for all of them (in terms of hardware. screensaver needs long-press on o_C); to check whether that's indeed happening, can you comment out line #1942-#1945 in APP_CLK?


Hmmm... OK - I tried this and yes - the glitch goes away with those lines commented out.

Would the 100n on the 3.3v line between the 78L33 and the display be a likely culprit if I had the wrong value there? (would need to desolder tomorrow to check the value) I'm guessing here, but I was building these two side by side at the same time, so a misplaced part could have happened on both units.

will need to do some reflow and check everything with the loupe tomorrow I guess.
mxmxmx
nevetsokyeron wrote:


Hmmm... OK - I tried this and yes - the glitch goes away with those lines commented out.

Would the 100n on the 3.3v line between the 78L33 and the display be a likely culprit if I had the wrong value there? (would need to desolder tomorrow to check the value) I'm guessing here, but I was building these two side by side at the same time, so a misplaced part could have happened on both units.

will need to do some reflow and check everything with the loupe tomorrow I guess.


weird, but i don't think the 78L33 has anything to do with it; that is just there to (separately) supply the display. i guess you could try to pull up the switch externally (10k or so from 3v3), but that shouldn't be necessary, normally. which encoders are you using?
nevetsokyeron
mxmxmx wrote:

weird, but i don't think the 78L33 has anything to do with it; that is just there to (separately) supply the display. i guess you could try to pull up the switch externally (10k or so from 3v3), but that shouldn't be necessary, normally. which encoders are you using?


Encoders are the same as I've used in previous builds - Bourns 652-PEC11R-4220F-S24 Pretty sure these are from the same batch/order as when I built my last 2 temps.

I did notice something funny - when I first plugged the teensy in to flash the firmware - I did not see the glitch when the module was powered from USB (having not cut the trace yet). However this was not consistent on the second one and all voltages seemed to be correct (3.24v at the display is still OK, yeah?)

Gonna go over everything tonight and will report back.
nevetsokyeron
Curious...

The problem I'm seeing is with the Teensy's.

I swapped the two newer teensys into my older temps modules and I'm seeing the same glitch. The two older teensys don't glitch.

What would happen if I enabled 144 MHz overclock instead of 120 MHz? (If the SPI clock has anything to do with the encoders or display)

(I tried it and it won't compile as TU_config.h is checking for F_CPU != 120000000)
mxmxmx
nevetsokyeron wrote:
Curious...

The problem I'm seeing is with the Teensy's.

I swapped the two newer teensys into my older temps modules and I'm seeing the same glitch. The two older teensys don't glitch.

What would happen if I enabled 144 MHz overclock instead of 120 MHz? (If the SPI clock has anything to do with the encoders or display)

(I tried it and it won't compile as TU_config.h is checking for F_CPU != 120000000)


that's weird. they're all 3.2, i assume? anyways, even so, i don't know what might be the issue, unlikely that you got two faulty ones. (and if so, what's at fault)

the SPI clock shouldn't impact on the encoders or v.v.; but you can try, if you want. simply comment out that line or make is say F_CPU != 144000000
Dark Barn
Can TU be slaved to an external clock running at 24 PPQN?
gimber
Dark Barn wrote:
Can TU be slaved to an external clock running at 24 PPQN?


You'd just have to adjust the divisions of each channel accordingly. /6 if you wanted them to run at 16ths, etc.

That said, I still usually divide my 24ppq source by 6 before going into the temps because it's more intuitive for me that way.
mxmxmx
gimber wrote:
Dark Barn wrote:
Can TU be slaved to an external clock running at 24 PPQN?


You'd just have to adjust the divisions of each channel accordingly. /6 if you wanted them to run at 16ths, etc.

That said, I still usually divide my 24ppq source by 6 before going into the temps because it's more intuitive for me that way.


yeah, it'll track but there aren't any explicit/global PPQN settings, which make it more intuitive. the currently available multiplier/divider options are:

/64, /48, /32, /24, /16, /12, /8, /7, /6, /5, /4, /3, /2, /1, x2, x3, x4, x5, x6, x7, x8, x12, x16, x24, x32, x48, x64
Dark Barn
Thanks Max! Any thoughts on adding a global 24 PPQN input setting so that the divisors behave in a fashion that isn't a multiple of 3? I have a few things that send 24 PPQN in my system (Grids and Shuttle Control) that I would love to slave TU to, mostly the Shuttle Control, but sometimes Grids too smile
mxmxmx
Dark Barn wrote:
Thanks Max! Any thoughts on adding a global 24 PPQN input setting so that the divisors behave in a fashion that isn't a multiple of 3? I have a few things that send 24 PPQN in my system (Grids and Shuttle Control) that I would love to slave TU to, mostly the Shuttle Control, but sometimes Grids too :)


i haven't thought about it all that hard, i must admit. i vaguely was thinking there should/could be a global settings menu; the rest should be fairly straightforward, basically adding a counter to CLOCKS_isr(), if i see it right.
Macc29
Ok; Temps U built. Works, except encoders do nothing. First rev board. Pushing them works, but in calibration mode I can't change anything. Used a compiled hex.

I trued to compile a new one myself, but boards.txt is greyed out, so I can't do anything.

Now I need either a hex file which works with the old board, or somebody tells me why boards.txt is greyed out confused Please.
mxmxmx
Macc29 wrote:
Ok; Temps U built. Works, except encoders do nothing. First rev board. Pushing them works, but in calibration mode I can't change anything. Used a compiled hex.

I trued to compile a new one myself, but boards.txt is greyed out, so I can't do anything.

Now I need either a hex file which works with the old board, or somebody tells me why boards.txt is greyed out :/ Please.


i don't know why it would be greyed out. have you followed these instructions? https://github.com/mxmxmx/temps_utile-/wiki/firmware (just updated them to reflect the latest IDE / add-on versions, which make it somewhat simpler — there's no need any more to edit the boards.txt file to enable overclocking)

if you prefer, i can also send you a hex file.
Macc29
I did all that, but same happened as with another new (?) hex: black screen, nothing. When I try some hex "temps_utile_rev_120MHz.hex" it sort of works - but not in calibration mode, encoders do not work there.

Weird.
Macc29
..and what does this mean: " uncomment L#8 if using revision 0 pcbs (typically, yellow pcbs):"
mxmxmx
Macc29 wrote:
I did all that, but same happened as with another new (?) hex: black screen, nothing.


ah, i thought the boards.txt file was greyed out. but if the screen is black, yes, you need to edit one line of code. as per the instructions, https://github.com/mxmxmx/temps_utile-/wiki/firmware#step-4-compile

Quote:
uncomment the line that says #define _TEMPS_UTILE_REV_0 (in TU_gpio.h).


this line: https://github.com/mxmxmx/temps_utile-/blob/master/soft/t_u_REV/TU_gpi o.h#L8

simply remove the two // at the beginning of the line. then recompile, it should work. (that's because those earlier versions use a different set of pins).

that said, i don't know why the encoders wouldn't work with that other hex.
Macc29
With your new instructions the greying on board.txt is no problem any more. BUT; with that hex it _does not_ work. Blank screen. With "temps_utile_rev_120MHz.hex" it works, but NOT in calibration mode.

So: if you could please send me some hex, I will try that.
Macc29
I just noticed that my buttons do not work, so the switches are wrong type. Should they connect the two topmost pins in pcb or which ones? Actually, the two bottom ones are already connected on pcb.
mxmxmx
Macc29 wrote:
I just noticed that my buttons do not work, so the switches are wrong type. Should they connect the two topmost pins in pcb or which ones? Actually, the two bottom ones are already connected on pcb.


let's don't rush things. so far we had:

greyed out files
blank screen
non-working encoders
non-working buttons

don't worry about the buttons just yet, try to get the latest firmware working first. but i don't know why that old hex should work, but not when you compile the up-to-date version. the only difference between the versions is the pin usage, which is what the _TEMPS_UTILE_REV_0 switch handles. blank screen suggests the code was compiled for newer boards. working screen but non-working buttons/encoders would suggest hardware issues.
Macc29
Thank you very much for your help Sir. With try and error-method now the encoders AND buttons work (had to turn them 90 degrees)! But 11 volts out is a bit much, but there was an instruction how to get this down right? Update: even that seems to be okay now!

Ah. Great. I am very grateful grin
mxmxmx
Macc29 wrote:
Thank you very much for your help Sir. With try and error-method now the encoders AND buttons work (had to turn them 90 degrees)! But 11 volts out is a bit much, but there was an instruction how to get this down right? Update: even that seems to be okay now!

Ah. Great. I am very grateful


ok, great. weird though!
wavefold
I have a TU in my backlog, can't wait to build it! anyway I was wondering how hard would be to implement a delay per output on the various modes (if it's not already there)
Macc29
Oh, I forgot one thing: I did not have a 78L33 so I took 3.3V from Teensy as Mxmxmx said you could do. It seems to work well with Teensy 3.2 at least smile
mxmxmx
mr.freeman wrote:
I have a TU in my backlog, can't wait to build it! anyway I was wondering how hard would be to implement a delay per output on the various modes (if it's not already there)


you mean like swing? shouldn't be too hard, but i'd really have to clean up the timer code before adding yet more stuff.

speaking of / fwiw, i've tried to improve a bit on the channel #4 / DAC modes, adding a few more parameters/settings (offset, basic sequencer, and so on):

https://www.instagram.com/p/BQh5-uAlFHP/

(quick crappy video featuring output #D in "ARP" mode.)

https://github.com/mxmxmx/temps_utile-/tree/1_1

it also fixes some bugs. (so i'll merge it into master sooner or later). to use it, you'll have to re-calibrate. (there's a couple of additional calibration points now: -4V, -2V, 0V, +2V, +4V. the precision isn't too great, of course, but usable)
xbted
I keep getting this error code when I try to compile:

Arduino: 1.6.5 (Windows 8.1), TD: 1.26, Board: "Teensy 3.2 / 3.1, Serial, 120 MHz optimized (overclock), US English"

In file included from C:\Users\Ted\AppData\Local\Temp\build3110426070498641560.tmp\streams_l orenz_generator.cpp:36:0:
C:\Users\Ted\AppData\Local\Temp\build3110426070498641560.tmp\streams_l orenz_generator.h:38:30: fatal error: util/util_macros.h: No such file or directory
#include "util/util_macros.h"
^
compilation terminated.
Error compiling.

Any suggestions? I'm sure its something simple, but i just don't recognize it.

Ted
mxmxmx
xbted wrote:
I keep getting this error code when I try to compile:

Arduino: 1.6.5 (Windows 8.1), TD: 1.26, Board: "Teensy 3.2 / 3.1, Serial, 120 MHz optimized (overclock), US English"

In file included from C:\Users\Ted\AppData\Local\Temp\build3110426070498641560.tmp\streams_l orenz_generator.cpp:36:0:
C:\Users\Ted\AppData\Local\Temp\build3110426070498641560.tmp\streams_l orenz_generator.h:38:30: fatal error: util/util_macros.h: No such file or directory
#include "util/util_macros.h"
^
compilation terminated.
Error compiling.

Any suggestions? I'm sure its something simple, but i just don't recognize it.

Ted


can you try upgrading to the latest stable versions of arduino/TD? (1.8.1/1.35). that should compile

there were some changes to the precompiler stuff at around 1.6.9 IIRC, which required some shuffling around of includes etc, maybe it's that
xbted
Hey Max,

After I posted, I realized that I should update. Afterwards I got another error, however, it looks like I found the answer, probably, maybe... I'll let ya know!

Ted
mxmxmx
weird, it's probably some windows thing?

fwiw, as i'm not going to be able to change/add much in the coming few weeks, i've just uploaded a hex.
xbted
Oh, now we have the hex, LOL!!! That's cool, everything I've learned about computers and electronics is from messing stuff up.

So, basically, I had to erase everything Arduino at all on my computer, from everywhere.

Then, I reloaded Arduino as Admin, reboot. Loaded Tinyduino as Admin, reboot. Then just ran Arduino as Admin and voila! I'm not sure why the specificity, but just doing everything as admin took care of it. I think windows wasn't sure which folder to be using, etc...

So, there we go!

YAY!!!!
xbted
Ok, so I was able to pin it down to needing to run Arduino as an administrator. If I do that, then everything is fine.

If I try to run Arduino by double clicking the tool bar or whatever, I get the error messages.

I really need to expand my Linux partition so this kind of crap stops happening.

Dead Banana
Virgil
I've just tried to calibrate a temps utile. However, instead of the five calibration points that have to be adjusted according to the wiki (-4V, -2V, 0V, +2V, +4V ), there is only one entry for the DAC calibration (0.0 volts). After that it directly jumps to the CV offset step. Have I missed something? I've compiled the latest firmware (well, last week).
mxmxmx
Virgil wrote:
Have I missed something? I've compiled the latest firmware (well, last week).


yep -- that was merged in only a couple of days ago. you'll have to update your local repo, or copy, and recompile; or go here.
Virgil
That's much better, thanks smile
wavefold
mxmxmx wrote:
mr.freeman wrote:
I have a TU in my backlog, can't wait to build it! anyway I was wondering how hard would be to implement a delay per output on the various modes (if it's not already there)


you mean like swing? shouldn't be too hard, but i'd really have to clean up the timer code before adding yet more stuff.


yep some kind of swing would be super nice! thumbs up
boerker
hi,
I don´t know if anyone ever had this problem but if so this tip could be a time safer. It took me some time to figure it out...

After hours of debugging and uploading the firmware again and again because the OLED stayed black I took the OLED from my O_C and compared it with the one I bought for temps. And behold there was a small difference.

These displays can be configured as SPI or IIC by swapping a resistor. For the temps the resistor has to be on the SPI place


mxmxmx
boerker wrote:
hi,
I don´t know if anyone ever had this problem but if so this tip could be a time safer. It took me some time to figure it out...


ups, i've never actually seen/gotten one configured for i2c, but i kind was waiting for this to happen. sorry for the hassle ... should have included a note making sure that people double-check. (will do so asap).
mxmxmx
mxmxmx wrote:
Dark Barn wrote:
Thanks Max! Any thoughts on adding a global 24 PPQN input setting so that the divisors behave in a fashion that isn't a multiple of 3? I have a few things that send 24 PPQN in my system (Grids and Shuttle Control) that I would love to slave TU to, mostly the Shuttle Control, but sometimes Grids too :)


i haven't thought about it all that hard, i must admit. i vaguely was thinking there should/could be a global settings menu; the rest should be fairly straightforward, basically adding a counter to CLOCKS_isr(), if i see it right.


fwiw / as this came up every now and then, i've just added a couple of PPQ input settings: https://github.com/mxmxmx/temps_utile-/tree/1_1

to try/use it, long-press the right encoder, select "global settings", then the global divisor (24, 48, 96), and go back the main app ... feedback welcome (ie does it work?, does it break things?); i haven't tested this extensively (and in fact don't have any things with PPQN output to test with, so...)
Dark Barn
Thanks Max! I guess it's time I learn how to compile these things. I'll give it a spin as soon as I can get a grip on it!
n0rd
SEQ mode is not working as expected.

Steps to reproduce:
Reset module (long left encoder press).

Set Out1, 2 and 3 to mode "SEQ"
Edit all sequences to be 'Length 4': On, Off, Off, Off)
Sync (Left encoder press).
Notice Out1, 2 and 3 are all the same.

Now, change Out2 to '/2' and Out3 to '/4'.
Sync (Left encoder press).

Expected out (All outs sync and repeat after 16 clocks)
Code:

Out1 [ -]   X---X---X---X---X---X---X
Out2 [/2]   X-------X-------X-------X
Out3 [/4]   X---------------X-------


Actual:
Code:

Out1 [ -]   X---X---X---X---X---X---X--
Out2 [/2]   --X-------X-------X-------X
Out3 [/4]   ------X---------------X----


Steve
mxmxmx
n0rd wrote:
SEQ mode is not working as expected.


mmh, i can't check/try right now but i have a suspicion. does this work any better? thanks for reporting!
sempervirent


If you haven't built one yet, I'm doing a preorder for panels/PCBs this month (thanks mxmxmx):

http://grayscale.info/panels/mxmxmx-temps-utile/
http://grayscale.info/panels/mxmxmx-temps-utile-pcb/
n0rd
mxmxmx wrote:
n0rd wrote:
SEQ mode is not working as expected.


mmh, i can't check/try right now but i have a suspicion. does this work any better? thanks for reporting!

Yes, works as expected now.
n0rd
sempervirent wrote:

Shouldn't inputs be labelled 'TR1' and 'TR2' instead of 'CLK' and 'RST'? (Because you can, if you want, set TR1 to be reset and TR2 to be clock or set both TR's to be Clock1 and Clock2 etc etc)
bemerritt
n0rd wrote:
sempervirent wrote:

Shouldn't inputs be labelled 'TR1' and 'TR2' instead of 'CLK' and 'RST'? (Because you can, if you want, set TR1 to be reset and TR2 to be clock or set both TR's to be Clock1 and Clock2 etc etc)


Agree with this^

Stoked to get a proper panel on my build!
mxmxmx
bemerritt wrote:
n0rd wrote:
sempervirent wrote:

Shouldn't inputs be labelled 'TR1' and 'TR2' instead of 'CLK' and 'RST'? (Because you can, if you want, set TR1 to be reset and TR2 to be clock or set both TR's to be Clock1 and Clock2 etc etc)


Agree with this^


yeah ideally it would say TR2.

n0rd wrote:
mxmxmx wrote:
n0rd wrote:
SEQ mode is not working as expected.


mmh, i can't check/try right now but i have a suspicion. does this work any better? thanks for reporting!

Yes, works as expected now.


cool, thanks for trying ... i'll merge the fix into the master once i've received some feedback on the global divider stuff, which is also in that branch.
bemerritt
If you have a hex with the global divider i can check it with my circadian tonight. Otherwise I'll try and spend some time tonight figuring out how to compile the firmware, which I have been meaning to do anyways.
mxmxmx
bemerritt wrote:
If you have a hex with the global divider i can check it with my circadian tonight. Otherwise I'll try and spend some time tonight figuring out how to compile the firmware, which I have been meaning to do anyways.


here we go ... thanks! usage is as per the post on the previous page.
Timmy
n0rd wrote:
sempervirent wrote:

Shouldn't inputs be labelled 'TR1' and 'TR2' instead of 'CLK' and 'RST'? (Because you can, if you want, set TR1 to be reset and TR2 to be clock or set both TR's to be Clock1 and Clock2 etc etc)


The Oscillosaurus panel for Temps Utile is labelled in the preferred generic fashion, with the optional continuous behaviour of the D output channel elegantly denoted by a gold ring around the jack.

sempervirent
Thanks for the feedback, I've updated the CLK/RST to TR1/TR2 graphics.
bemerritt
Well here is video of it working. You can see channel 1 of the circadian with the top led syncing up with the middle led, which is triggered by channel 1



It didnt seem to be working correctly, buso i went back to the global settings and when I switched back, all was in sync.

Hard to see on the screen in the video, but I am scrolling the mult/div value and you can see the led stay in relative sync.

Turn your volume down, unless you want to listen to my wife watching the bachelor. screaming goo yo
bemerritt
Couldn't get it to reproduce the problem. I did have some trouble syncing up the beats using the reset. Got around it by power cycling my rig and it fired up in time.

Thanks for this, can now have circadian be my master without crazy divisions, which is just the way I would like it setup.

edit: Scratch that, having trouble syncing up the "beats"
mxmxmx
bemerritt wrote:
Couldn't get it to reproduce the problem. I did have some trouble syncing up the beats using the reset. Got around it by power cycling my rig and it fired up in time.

Thanks for this, can now have circadian be my master without crazy divisions, which is just the way I would like it setup.

edit: Scratch that, having trouble syncing up the "beats"


thanks for trying. so the issue is with sync in general or with reset?

fwiw, as is, the global divider is really just that, a divider, so things should stay in sync (that should work), but they are unlikely to stay in phase. i think (?) to play nicely with 24PPQ outputs there would have to be some run/stop input feature to actually make this work. or how is this commonly done?
Dark Barn
Either with run/stop or reset pulses.
bemerritt
Yeah, in phase was my issue. I was using a reset pulse to no avail. I'll try again tonight. Very well could be the reset pulse not being configured right, but it has been working for me in the past.
mxmxmx
bemerritt wrote:
Yeah, in phase was my issue. I was using a reset pulse to no avail. I'll try again tonight. Very well could be the reset pulse not being configured right, but it has been working for me in the past.


ok, i see. and don't try, the global divider won't reset as is, only the channel dividers will. i think what i'll do is limit the PPQ input option to TR1 and have TR2 default to global "reset" in that case, ie disable all the other options which are unlikely to make a whole lot of sense in that scenario.
mxmxmx
mxmxmx wrote:
bemerritt wrote:
Yeah, in phase was my issue. I was using a reset pulse to no avail. I'll try again tonight. Very well could be the reset pulse not being configured right, but it has been working for me in the past.


ok, i see. and don't try, the global divider won't reset as is, only the channel dividers will. i think what i'll do is limit the PPQ input option to TR1 and have TR2 default to global "reset" in that case, ie disable all the other options which are unlikely to make a whole lot of sense in that scenario.


ok, second attempt. i didn't have time to test this much, but things *should* reset globally now if TR2 goes high *and* channel #1 is set to "reset/mute = TR2".

... in other words, channel 1 is a bit special in that it resets the global divider when the setting is either PPQ24, PPQ48 or PPQ96; it can also be switched off by setting "reset/mute" to " - ", much like the channel reset. it's probably not ideal ... but i haven't had a better idea yet given the constraints of the module / two clock inputs only.

let me know how this goes. i'm not sure even i entirely understand the use case scenario, like why would you slave something to a fast clock, then sync the derived clock to a slower clock, which itself is derived from said fast clock?
bemerritt
I guess my use is syncing it to the fast clock, but wanting it to be in phase with a slower clock.

For example, wanting everything to be in phase with a bass drum on first and third beat. Could clock the temps from the bass drum trigger, but then any variations or mutes mess with it.

Could setup a different channel to send a pulse to temps, but that uses up a channel.

So i guess, in essence, its wanting to use the clock out to simplify and not use up a channel.

This is of course a specific use case, but seems like it could be a somewhat common one? seriously, i just don't get it
abozzelli
Playmodes fwd, rev, pendulum and random in SEQ mode would be nice. hyper
The possibility to set probability, delay and repeat (per step) in SEQ mode would be amazing SlayerBadger!
mxmxmx
bemerritt wrote:
I guess my use is syncing it to the fast clock, but wanting it to be in phase with a slower clock.

For example, wanting everything to be in phase with a bass drum on first and third beat. Could clock the temps from the bass drum trigger, but then any variations or mutes mess with it.

Could setup a different channel to send a pulse to temps, but that uses up a channel.

So i guess, in essence, its wanting to use the clock out to simplify and not use up a channel.

This is of course a specific use case, but seems like it could be a somewhat common one? :despair:


oh, i'm sure it must be somewhat common, you're not the first to request it... it's just i haven't entirely gotten my head around this 24PPQ business in a modular context, and have zero practical experience using it, so i'm sure i'm doing the right thing. anyways, what should work at this point is slaving to a 24/48/96 source / divide it down to 1/24, 1/48, or 1/96, and reset he global divider via channel #1/TR2. that'll also reset the channel #1 internals (local divider, sequences, euclidian mode). so that should work at this point, as far as i can see, provided the clock and reset signals are in phase. if the reset signal lags behind, so will the TU outputs.


abozzelli wrote:
Playmodes fwd, rev, pendulum and random in SEQ mode would be nice.
The possibility to set probability, delay and repeat (per step) in SEQ mode would be amazing


sure, when i get around it it i guess i can move the direction stuff from OC/Sequins to TU; i figured that's more interesting in a CV context, so didn't do it yet. re: per step parameters: unlikely, mainly because of the UI limitations. if there were more buttons ... it wouldn't be such a big deal, but as things are, i'm not so sure it can be done nicely. i suppose there might be a way doing repeats at least by adding a second layer of edit windows, which could be accessed by long-pressing the left encoder or something. i'll think about it.
abozzelli
mxmxmx wrote:

sure, when i get around it it i guess i can move the direction stuff from OC/Sequins to TU; i figured that's more interesting in a CV context, so didn't do it yet.


SlayerBadger! we're not worthy

mxmxmx wrote:

re: per step parameters: unlikely, mainly because of the UI limitations. if there were more buttons ... it wouldn't be such a big deal, but as things are, i'm not so sure it can be done nicely. i suppose there might be a way doing repeats at least by adding a second layer of edit windows, which could be accessed by long-pressing the left encoder or something. i'll think about it.


I thought it was "easier" adding a menu voice under "--> edit" for each parameter. So you have:

--> edit
--> edit prob
--> edit delay
etc...
etc...

clicking on the menu open a window with a copy of the sequence(uneditable), left encoder to scroll step and right encoder to change value (same OC UI pattern).
In any case, anything else would be a blessign to us lol
mxmxmx
abozzelli wrote:


I thought it was "easier" adding a menu voice under "--> edit" for each parameter.


we'll see. we're just toying around with some per-step parameter stuff in OC, anyways, so perhaps that'll work out as mostly a spin-off:



no promises though this is going to happen any time soon ...


re directions: fwiw/in the meantime, you can try the dev branch, to which i've added an additional sequencer "playmode" called SH, which you can use to CV address the sequence steps; with that you can feign, sort of, the various direction-patterns (random, pendulum, etc) as well as do other things, burst-like behaviour and so on.
Devi
were can i buy the pcbs?
mxmxmx
Devi wrote:
were can i buy the pcbs?


i have a batch on order, should be getting here sometime next week.

or if you're in the US another option is http://grayscale.info/panels/mxmxmx-temps-utile-pcb/

yet another option is magpie, but they're currently sold out, it looks like. and i think synthcube will have them sooner or later. modularaddict only has the panels, iirc.
n0rd
n0rd wrote:
mxmxmx wrote:
n0rd wrote:
SEQ mode is not working as expected.


mmh, i can't check/try right now but i have a suspicion. does this work any better? thanks for reporting!

Yes, works as expected now.


It seems that if you rotate the sequence (right encoder when editing the sequence) the issue described before returns.

Steve
mxmxmx
n0rd wrote:
n0rd wrote:
mxmxmx wrote:
n0rd wrote:
SEQ mode is not working as expected.


mmh, i can't check/try right now but i have a suspicion. does this work any better? thanks for reporting!

Yes, works as expected now.


It seems that if you rotate the sequence (right encoder when editing the sequence) the issue described before returns.

Steve


mmh, "rotate" and sync should be/are fairly independent, and i can't seem to reproduce it here, but then i'm not sure i'm doing the right thing or what kind of behaviour you'd expect. so is that with rotate via CV, or when rotating manually, or both? same scenario as described above?
n0rd
mxmxmx wrote:
n0rd wrote:
n0rd wrote:
mxmxmx wrote:
n0rd wrote:
SEQ mode is not working as expected.


mmh, i can't check/try right now but i have a suspicion. does this work any better? thanks for reporting!

Yes, works as expected now.


It seems that if you rotate the sequence (right encoder when editing the sequence) the issue described before returns.

Steve


mmh, "rotate" and sync should be/are fairly independent, and i can't seem to reproduce it here, but then i'm not sure i'm doing the right thing or what kind of behaviour you'd expect. so is that with rotate via CV, or when rotating manually, or both? same scenario as described above?


Apologies for not being clear. I was trying to say that rotating a sequence a certain amount then rotating back to it's original position throws the timing/sync out like before.

However, I don't think it's the rotation but the sequence length which causes it.

Steps to reproduce:
Reset module (long left encoder press).

Set Out2 to "SEQ" mode.
Set Out2 to Multiply by four (x4).
Set Out2 sequence to "X---X---X---X---"
Change Out2 sequence length to say 7 or 9 (non factor of 2, 4 or 8) and let it play for a bit.
Change Out2 sequence length back to 4 or 8 etc.
Sync (Left encoder press).
Notice Out1 and Out2 will (most of the time) be out of sync. (If they are still in sync then repeat Out2 sequence length change and back).

Steve
mxmxmx
ah, ok. i see now. i think that's because of the 4x multiplier: the sync didn't wait for a clock, but it should.

here is a quick fix. the channels may still end up relatively out of sync, e.g. the slower sequence might fire on 9th or the 13th step of the 4x sequence, rather than on the 1st (sticking with your example). i'm not sure that's hugely important, but it would need a slightly more elaborate scheme to fix (mainly because the 6 channels are more or less independent, which has its advantages; but not so much when in comes to staying in sync.)

also fyi, there's also a half-cooked new mode in that branch ("BURST"), which still needs some fine-tuning though.
n0rd
mxmxmx wrote:
here is a quick fix. the channels may still end up relatively out of sync

It seems to work however I've only tested it briefly.
mxmxmx
n0rd wrote:
mxmxmx wrote:
here is a quick fix. the channels may still end up relatively out of sync

It seems to work however I've only tested it briefly.


ok, great. thanks for trying. as i said, the re-sync will be relative to an incoming clock, which should prevent multiplying channels from drifting off the grid when resetting them, but that won't work in all circumstances/scenarios (e.g. when both dividing _and_ multiplying) ... there's no master channel really, or scheme to keep track of division/multiplication settings across channels, but there probably should be, eventually.

in other news / fyi: a few people had inquired re PCBs but i didn't properly keep track of names. please get in touch if i don't -- a bunch of them came in today....

LSuveg1
[text moved to next post w/photo]
LSuveg1
I've got a calibration question -- I'm only reading a max of 2.48 volts from each of the digital outputs, and about 1.03 volts from the DAC. My CV inputs, at least, are calibrated (all are ~2048, some as high as 2055, which from the instructions seem acceptable), and a clock (from Yarns) into input 1 is indeed passing the signal to each of the outputs, but the values are much lower than those specified on the github page (10V, 6V). Any suggestions for increasing the output voltage? Here's a pic of the board:
mxmxmx
LSuveg1 wrote:
I've got a calibration question -- I'm only reading a max of 2.48 volts from each of the digital outputs, and about 1.03 volts from the DAC. My CV inputs, at least, are calibrated (all are ~2048, some as high as 2055, which from the instructions seem acceptable), and a clock (from Yarns) into input 1 is indeed passing the signal to each of the outputs, but the values are much lower than those specified on the github page (10V, 6V). Any suggestions for increasing the output voltage?


mmh, that's odd. how are you measuring the output levels? the default pulse-width is just 25ms, which might not be enough for your DMM to register. try setting the pulse-width setting to "50%" (that's all the way up to/beyond 255), and the multiplier/divisor to, say, /16. that will result in a much longer period.

either way, things shouldn't be attenuated. the digital logic is 3v3, and with 10k/20k in the output stage, the gain will be 3 (see here), which should be plenty.
LSuveg1
The pulse width/divisor adjustments seemed to do the trick for the digital outputs, and (to an extent) with the DAC -- I can measure 9.9V at each digital output now, and up to 4V from the DAC. I'm measuring using a cable attached to the test leads using alligator clips attached to my DMM probes; the selected limit is 20V on the DC setting. Maybe it's just a multimeter issue? Regardless, the module works fine for triggering and as a clock divider. Thanks!
mxmxmx
LSuveg1 wrote:
The pulse width/divisor adjustments seemed to do the trick for the digital outputs, and (to an extent) with the DAC -- I can measure 9.9V at each digital output now, and up to 4V from the DAC.


if you didn't run into problems when tuning the 5 calibration points, the DAC channel should be ok, i guess. it should be more like +4.75V max (the DAC channel gain is ~ 2.88), not sure why i thought it's +6V max, updated the page with the correct numbers.

fwiw/if you'd prefer, you can make the DAC output unipolar (0V — 9.5V) by removing the 3.9k resistor on the far right, right next to the 470n cap. that'll need a few adjustments to the code, some of the non-clock DAC modes would swing around 4.75V otherwise. i might add that as a compile option ... i always meant to add some LFO type stuff, hence the bipolar output, but i'm not sure i'll ever do this.
gimber
How possible might it be to port grids over to this as an additional app? Is there enough space on the teensy to hold the standard tu firmware and grids? The controls would be lacking over the original, but with assignable CV like the other temps modes it could work.

Also - is it possible to select the output of one channel as the clock source for another channel? This seems like it's not necessarily a hardware limitation since the logic mode sort of does this already.

Absolutely loving the module the way it is now, btw, just daydreaming.
mxmxmx
gimber wrote:
How possible might it be to port grids over to this as an additional app? Is there enough space on the teensy to hold the standard tu firmware and grids? The controls would be lacking over the original, but with assignable CV like the other temps modes it could work.


sure, should be entirely feasible ... only someone needs to port it. i wasn't going to, so it's unlikely to actually ever happen. but there's still plenty of space left, and quite generally of course the teensy/MK20 chip has more oomph than the AVR/atmega328.

gimber wrote:

Also - is it possible to select the output of one channel as the clock source for another channel? This seems like it's not necessarily a hardware limitation since the logic mode sort of does this already.


the logic modes already kind of do this, yeah, but doing it properly would be kind of involved, i think. you'd need some kind of priority scheme keeping track of what to update when, sequentially, depending on the logic and (hypothetical) source settings. the logic mode as is doesn't actually care all that much, so will tend to lag behind one clock, rather than reflect the current output state (ie when logic operations are performed on channels performing logic operations), because the channels just update in a fixed order, no matter what.
gimber
mxmxmx wrote:

sure, should be entirely feasible ... only someone needs to port it. i wasn't going to, so it's unlikely to actually ever happen. but there's still plenty of space left, and quite generally of course the teensy/MK20 chip has more oomph than the AVR/atmega328.


Thanks for the explanation! Good to hear it's not outright impossible with the current hardware.
mxmxmx
gimber wrote:
mxmxmx wrote:

sure, should be entirely feasible ... only someone needs to port it. i wasn't going to, so it's unlikely to actually ever happen. but there's still plenty of space left, and quite generally of course the teensy/MK20 chip has more oomph than the AVR/atmega328.


Thanks for the explanation! Good to hear it's not outright impossible with the current hardware.


it's definitely not outright impossible. in terms of 'apps', the grids stuff admittedly is a good candidate, i guess i'm just not very keen on it personally. anyways, there's plenty of program space left for adding stuff ... the reason there's only one app is mainly lack of ideas and the fact that pretty much every basic variation on clocks i could think of was crammed into that one app.
pirxthepilot
I just got the nice Oscillosaurus panel from Modular Addict, and I'm planning to order the grayscale PCB to match. I would suppose the measurements are identical across different PCB manufacturers, but I just want to make sure? Thanks!
mxmxmx
pirxthepilot wrote:
I just got the nice Oscillosaurus panel from Modular Addict, and I'm planning to order the grayscale PCB to match. I would suppose the measurements are identical across different PCB manufacturers, but I just want to make sure? Thanks!


yes, they'll all be the same.
Sven
Question about Temps. When I clock the module with an external clock the outputs with a multiplication >0 (x8 for example) don't stop when I stop the clock or retire the clock in source. Only stops if I put the mult option in 0 or less. But If i put the mult in any parameter >0 again (even if dont have a clock in) the outputs works again. Any solution?
mxmxmx
Sven wrote:
Question about Temps. When I clock the module with an external clock the outputs with a multiplication >0 (x8 for example) don't stop when I stop the clock or retire the clock in source. Only stops if I put the mult option in 0 or less. But If i put the mult in any parameter >0 again (even if dont have a clock in) the outputs works again. Any solution?


no, that's be design, most clock multipliers will do that (e.g. 4ms SCM), unless, i guess, they have some way to detect the jack has been removed, which wouldn't even cover all scenarios though (like simply stopping the clock, but not removing the patch cable). that's because to derive the output, you have to measure the incoming frequency; that'll involve at least two consecutive pulses and there's no telling really if/when the clock will stop or the user removes the cable.
sammy123
I FINALLY finished this! I have this rev 1 blue PCB for a long time. Totally loving it so far. I am so happy to finally have a clock multiplier in my setup.

I did manage to remove the wrong part from the Teensy. I don't what my problem is lately but I have been messing up all kinds of stuff on my builds lately. Anyway it took me forever to figure out what I removed...turns out it was a fuse so I just jumpered it...at least I think it was a fuse. hihi

Everything is working good, but of course I do have a few questions.

My output voltages are about 9.88 and 4.11. Is that close enough? I went through the calibration twice without issue.

Also, the 330n cap is not listed in the build guide. I used a standard ceramic for this. Does it need to be a C0g or anything else fancy?

And, I used standard SMD ceramics for the 10n. Is it worth upgrading later to C0g?

Anyway thank you Max and others who contributed.
mxmxmx
sounds all good -- the DAC output is maybe a little low, it should be more like 4.75V (the gain is ~ 2.89, *3.3V/2). as long as it triggers stuff, and the calibration went ok, it's probably good though. if you wanted to increase the gain somewhat, one of the 3.9k resistors is labelled "** gain adj." : if you lower that to 3k, the gain would be 3.76, 3.3k would give you -3.41.

330n i think was turned into 470n in the more recent version, to rationalize the BOM. standard ceramic will do. the 10n caps ideally should be C0G, but the quality of what ends up at the ADC isn't so hugely critical, most of the CV-able parameters have a fairly low resolution.
sammy123
Great. Thank you for the explanation.

I may even have the 10n C0G somewhere but my parts are scattered in boxes all over the place. eek!

Guinness ftw!
Dunk_91
Hello everyone, is there a way to set an output to send start\stop gate? (ie: when clock is running the outpust stay high, when stopped the output goes low)
It would be really useful, especially using it with dinsync sequencer! hihi
mxmxmx
Dunk_91 wrote:
Hello everyone, is there a way to set an output to send start\stop gate? (ie: when clock is running the outpust stay high, when stopped the output goes low)
It would be really useful, especially using it with dinsync sequencer! :hihi:


no, there's nothing start/stop stuff going on whatsoever. i suppose if all was required is gate high/low, it could be added in some way or another. but how would this work? when clocked externally, there's no way knowing the clock is "running"; and when clocked internally, the clock is always on, kind of, there'd also have to be a start/stop button, no?
Dunk_91
mxmxmx wrote:
Dunk_91 wrote:
Hello everyone, is there a way to set an output to send start\stop gate? (ie: when clock is running the outpust stay high, when stopped the output goes low)
It would be really useful, especially using it with dinsync sequencer! hihi


no, there's nothing start/stop stuff going on whatsoever. i suppose if all was required is gate high/low, it could be added in some way or another. but how would this work? when clocked externally, there's no way knowing the clock is "running"; and when clocked internally, the clock is always on, kind of, there'd also have to be a start/stop button, no?


totally, was forgetting that there isn't a start\stop button, so my thoughts are pretty clueless MY ASS IS BLEEDING
whyfarer
First, thanks to all creators for making a great product freely available!

I've built my TU and loaded the software. All seemed fine until I tried to enter calibration. Although my right encoder turns and sends a signal, clicking it doesn't seem to do anything. I entered normal mode and the module responds to the left encoder turns and clicks. Any suggestions on debugging this on the board or is it most likely to be my encoder that needs to be replaced?

Cheers!
mxmxmx
whyfarer wrote:
Any suggestions on debugging this on the board or is it most likely to be my encoder that needs to be replaced?


it's probably not the encoder. the right encoder switch is connected (straight) to teensy pin 13 ("D13"), which is somewhat prone to cause trouble because that's where the onboard LED is connected to, too.

there's an extra 10k pull-up resistor, which should take care of that (that's the one adjacent to the 3V3 pin, underneath the teensy). double-check that; and if that doesn't help, removing the 100n cap right next to the encoder switch pin (PCB bottom side) might.
whyfarer
mxmxmx wrote:
whyfarer wrote:
Any suggestions on debugging this on the board or is it most likely to be my encoder that needs to be replaced?


it's probably not the encoder. the right encoder switch is connected (straight) to teensy pin 13 ("D13"), which is somewhat prone to cause trouble because that's where the onboard LED is connected to, too.

there's an extra 10k pull-up resistor, which should take care of that (that's the one adjacent to the 3V3 pin, underneath the teensy). double-check that; and if that doesn't help, removing the 100n cap right next to the encoder switch pin (PCB bottom side) might.


touching up the resistor did it. thanks! now off to break this puppy in hyper
trimix
whyfarer wrote:
mxmxmx wrote:
whyfarer wrote:
Any suggestions on debugging this on the board or is it most likely to be my encoder that needs to be replaced?


it's probably not the encoder. the right encoder switch is connected (straight) to teensy pin 13 ("D13"), which is somewhat prone to cause trouble because that's where the onboard LED is connected to, too.

there's an extra 10k pull-up resistor, which should take care of that (that's the one adjacent to the 3V3 pin, underneath the teensy). double-check that; and if that doesn't help, removing the 100n cap right next to the encoder switch pin (PCB bottom side) might.



I'm having almost the same problem - everything seems fine except the right encoder: it will select with a push, but turning it left or right does nothing. I've swapped encoders, removed the 402 resistor next to the LED on the Teensy 3.2, and removed the 100n cap near the switch pin. Still no joy.
Note: I have a rev1 board, and the LED on the Teensy has been removed, trace is cut. I used the hex file to flash (successfully), and that file was downloaded today.
Help!
mxmxmx
trimix wrote:
whyfarer wrote:
mxmxmx wrote:
whyfarer wrote:
Any suggestions on debugging this on the board or is it most likely to be my encoder that needs to be replaced?


it's probably not the encoder. the right encoder switch is connected (straight) to teensy pin 13 ("D13"), which is somewhat prone to cause trouble because that's where the onboard LED is connected to, too.

there's an extra 10k pull-up resistor, which should take care of that (that's the one adjacent to the 3V3 pin, underneath the teensy). double-check that; and if that doesn't help, removing the 100n cap right next to the encoder switch pin (PCB bottom side) might.



I'm having almost the same problem - everything seems fine except the right encoder: it will select with a push, but turning it left or right does nothing. I've swapped encoders, removed the 402 resistor next to the LED on the Teensy 3.2, and removed the 100n cap near the switch pin. Still no joy.
Note: I have a rev1 board, and the LED on the Teensy has been removed, trace is cut. I used the hex file to flash (successfully), and that file was downloaded today.
Help!


the encoder pins (right encoder) are connected straight to pins 15 and 16, so i'd double-check you get continuity there. the onboard LED/pin 13 thing is something different, ie that's the switch / a different signal.
trimix
[/quote]
the encoder pins (right encoder) are connected straight to pins 15 and 16, so i'd double-check you get continuity there. the onboard LED/pin 13 thing is something different, ie that's the switch / a different signal.[/quote]

Thanks. I found the problem - there was no continuity on the trace between pin 15 and the last via before that. So I kludged a wire from the pot leg to the bottom of pin 15, and it now works.

New development, however - on calibration procedure, I had no change on the DAC voltages when I rotated the encoder - they stayed at about 5.4v in all DAC settings on Output Jack D. So I have it 'calibrated' under default for now.
Anything I should do about it?
mcop
Here's two I've just finished. Having a lot of fun with them.
Thanks to all involved developing this.

mxmxmx
trimix wrote:


Thanks. I found the problem - there was no continuity on the trace between pin 15 and the last via before that. So I kludged a wire from the pot leg to the bottom of pin 15, and it now works.


perfect.

trimix wrote:
New development, however - on calibration procedure, I had no change on the DAC voltages when I rotated the encoder - they stayed at about 5.4v in all DAC settings on Output Jack D. So I have it 'calibrated' under default for now.
Anything I should do about it?


the calibration procedure isn't very critical, it's mainly to make sure output "D" is at ~ 0V when inactive/low, and to roughly output 1V/oct when using the arpeggiator. but output D won't work if it doesn't work, so yes, you should definitely do something about it ... so i take the output level isn't changing at all, ie not just during calibration? if so, double-check the output stage:

here's the output (not showing the offset, which is injected at C10); CLK4 = DAC = teensy pin "A14":




mcop wrote:
Here's two I've just finished. Having a lot of fun with them.
Thanks to all involved developing this.



he. cool, looks kind of flower power!
mxmxmx
fyi:

someone requested "hotter" outputs from the DAC / output #D ... support for which i've now added to the firmware. specifically (to play nice with the calibration procedure), this expects the DAC to output -2V / 7.25V (default would be -4.5V/4.5V).

to try, you'd only have to change one resistor (3k9 --> 10k). (see here):





... and recompile the code with #define MOD_OFFSET (see TU_options.h in this branch, which also includes some minor changes to the menus and sequencer/arpeggiator).
nso_music
any builders selling built TU's? (apologies if this is not the right place to ask screaming goo yo )
Altitude909
Would help if you stated where you're located
nso_music
Altitude909 wrote:
Would help if you stated where you're located


sure would! US, new england area
sduck
You could look in the Buy Sell Trade forum, there are several for sale currently.

Search isn't working currently, which makes it a bit of a hassle, but there's at least one near the first page...
PulletSurprise
I'm having an issue with accessing the CV menu. Long pressing the down button does nothing. Short pressing it works fine.

Board rev. 1c, firmware 1.2 (from pre-compiled HEX). Ideas?
sduck
Ok, here's an odd little problem. Sort of. I've built 3 of these things now. The second 2 work great, exactly as expected. The first one also works fine, but when calibrating the CV input offsets, the initial values are really high, like around 1300. They'll calibrate down to 0 just fine though. Any idea what may be causing this?
mxmxmx
sduck wrote:
Ok, here's an odd little problem. Sort of. I've built 3 of these things now. The second 2 work great, exactly as expected. The first one also works fine, but when calibrating the CV input offsets, the initial values are really high, like around 1300. They'll calibrate down to 0 just fine though. Any idea what may be causing this?


mmh, must be the offset. the input side works the same way as o_C, only the offset (at the pins) is / should be 1.65V, ie half the ADC range (see
here).

the pins in question are A3, A4, A5, and A6: if you probe them, i suspect the voltage you see must be off by 1V or so? if all four channels diverge consistently, the most likely cause of this would be the input resistors. those should be 100k — perhaps you put something else there? (on PCB versions prior to 1b it said "49k9" (though you're supposed to use 100k). maybe it's that? those haven't been available for a good while now, though).


PulletSurprise wrote:
I'm having an issue with accessing the CV menu. Long pressing the down button does nothing. Short pressing it works fine.

Board rev. 1c, firmware 1.2 (from pre-compiled HEX). Ideas?


mmh, but accessing the CV menu is via short pressing the down button. is that causing issues? there's no long-presses involved.

depending on which page you're on, long-pressing the down button either clears the CV mappings (assuming you have assigned any) or resets all channels to using the external clock (if on the BPM page, if any channel had been set to using the internal clock). either way, if short presses work, long presses will.
taichber
Are there plans to support a "shuffle mode" with the TU?

Maybe the the team is too bussy at the moment with the O_C development... Just asking...

(sorry if this has been discussed already but the search function does not work for me at the moment )
nevetsokyeron
taichber wrote:
Are there plans to support a "shuffle mode" with the TU?

Maby the the team is too bussy at the moment with the O_C development... Just asking...

(sorry if this has been discussed already but the search function does not work for me at the moment )


I brought it up in the past, but I don't think Max has had time to implement it.

FWIW - I noticed this fellow has added shuffle to his
Euclidean Polyrhythm generator code here:
https://github.com/tomduff/matrix-sequencer

Perhaps it would be possible to borrow some of his work?
mxmxmx
nevetsokyeron wrote:
taichber wrote:
Are there plans to support a "shuffle mode" with the TU?

Maby the the team is too bussy at the moment with the O_C development... Just asking...

(sorry if this has been discussed already but the search function does not work for me at the moment )


I brought it up in the past, but I don't think Max has had time to implement it.



truth is i was/am not terribly interested in "shuffle". but i suppose why not. not sure if/when that might happen, because it's summer, and so on.

nevetsokyeron wrote:

FWIW - I noticed this fellow has added shuffle to his
Euclidean Polyrhythm generator code here:
https://github.com/tomduff/matrix-sequencer

Perhaps it would be possible to borrow some of his work?



possible, but see above. just delaying the clock outputs isn't that complicated, anyways, so borrowing shouldn't be necessary (cleaning up the code first would help, but that's a different story).
toneburst
+1 for a shuffle feature here, too.

a|x
taichber
toneburst wrote:
+1 for a shuffle feature here, too.

a|x


I have not built yet the temps_utile - I have the PCB and panel already. I guess a shuffled clock input (e.g. from the squencer) would be a work arround. At least this works with my O_C.
ebardie
I've just built and am using my TU, and everything I've tested/tried so far is working smile

That is, everything's working aside from changing encoder direction.

Both encoders are the wrong way round - funny that, both being the same model and all wink - and I can successfully change either of their directions in the calibration mode.

What I can't do is change both directions at the same time.

TU seems to get stuck toggling between "R reversed" and "L reversed".

This pcb has been sitting around for a while. I think it's a rev 1.0.

Any suggestions as to what I've done/am doing wrong?
keninverse
I have an old rev1 pcb and it works. Just keep pressing the button until you have the right combination. Each button press will cycle through various combinations for encoder turn directions.
mxmxmx
hi,

yeah, that will work irrespective of the PCB revision. you just might have to push 2-3 times, as keninverse says. there's 4 possible permutations.
ebardie
Yes, that's how I thought it should work. But it's not what's happening here. The initial state was both encoders being the wrong direction, but now it only toggles between "R reversed" and "L reversed" no matter how many times I press the button.

It's not a major issue, just one of those weird glitches that I can't see a reason for why or how it's happening.

I might try reuploading the Teensy code when I get the TU out of the rack in the next rearrangement and see if that sorts it out.

Cheers both smile

Now on the TT build...
mxmxmx
ebardie wrote:
Yes, that's how I thought it should work. But it's not what's happening here. The initial state was both encoders being the wrong direction, but now it only toggles between "R reversed" and "L reversed" no matter how many times I press the button.

It's not a major issue, just one of those weird glitches that I can't see a reason for why or how it's happening.

I might try reuploading the Teensy code when I get the TU out of the rack in the next rearrangement and see if that sorts it out.


mmh, but that's not something re-uploading the code could possibly fix. either it's a bug, or it's not. but i'm fairly confident it works. i don't know why that is, but if, for whatever reason, you can't adjust the direction via the calibration menu, there's always the possibility to reverse the pin order in the code, ie here: https://github.com/mxmxmx/temps_utile-/blob/master/soft/t_u_REV/TU_gpi o.h#L56-#L62
pld
mxmxmx wrote:
ebardie wrote:
Yes, that's how I thought it should work. But it's not what's happening here. The initial state was both encoders being the wrong direction, but now it only toggles between "R reversed" and "L reversed" no matter how many times I press the button.

It's not a major issue, just one of those weird glitches that I can't see a reason for why or how it's happening.

I might try reuploading the Teensy code when I get the TU out of the rack in the next rearrangement and see if that sorts it out.


mmh, but that's not something re-uploading the code could possibly fix. either it's a bug, or it's not. but i'm fairly confident it works. i don't know why that is, but if, for whatever reason, you can't adjust the direction via the calibration menu, there's always the possibility to reverse the pin order in the code, ie here: https://github.com/mxmxmx/temps_utile-/blob/master/soft/t_u_REV/TU_gpi o.h#L56-#L62


It looks like the code in the master branch for TU only supports two states (normal/reversed), the advanced options probably got added to o_C a bit later than framework port. But that should mean that both encoders should always turn in the same direction, so I might be missing something obvious also...
mxmxmx
pld wrote:

It looks like the code in the master branch


ups, you're right. has it been that long? @ebardie: try here now https://github.com/mxmxmx/temps_utile- (you'll have to uncomment 1-2 lines in TU_options.h, depending on your PCB + desired DAC output level)
ebardie
Guinness ftw! Yay, that's sorted: thanks smile

Incidentally, https://github.com/mxmxmx/O_C/issues/5 applies to getting the TU firmware to compile on a case sensitive system too.
mxmxmx
ebardie wrote:

Incidentally, https://github.com/mxmxmx/O_C/issues/5 applies to getting the TU firmware to compile on a case sensitive system too.


ok, fixed this. uh, and, more importantly, fixed the outputs, too! ... (sorry, there was a little hick-up causing the various clock filters to be ignored)
lohacker
Hello Max,
could be possible to add internal attenuators for the CV inputs in the CV assign page?

Thanks, loving TU w00t
mxmxmx
lohacker wrote:

could be possible to add internal attenuators for the CV inputs in the CV assign page?


should be feasible. something like push left + turn right (?).
lohacker
mxmxmx wrote:
lohacker wrote:

could be possible to add internal attenuators for the CV inputs in the CV assign page?


should be feasible. something like push left + turn right (?).


I was just thinking about adding attenuation level in the CV assign menu under the relative voice, but your solution is of course more immediate, either way is good for me, thanks! thumbs up
DeWalta
im interested in the Temps utile, but im afraid that it also can't deal with shuffling (swing) incoming clocks. is that the case and does anyone know about this? how does the TU manage incoming swinging clocks?
mxmxmx
DeWalta wrote:
im interested in the Temps utile, but im afraid that it also can't deal with shuffling (swing) incoming clocks. is that the case and does anyone know about this? how does the TU manage incoming swinging clocks?


depends on what you mean by "dealing with". when dividing (/1, /2, /3, /4 etc), it'll simply track the incoming clock, that can shuffle as much as you like. the situation is trickier when multiplying, of course
wavedepletion
Finished build:





artistcalled6
could anyone that has already read through the code point me to the file where I can find the divisors for the clock dividing. I wanted to add some more to the list but I'm probably overlooking it as I read.

thanks
mxmxmx
....
mxmxmx
fwiw/fyi:

https://github.com/mxmxmx/temps_utile-/tree/sync_variation

dev branch that adds two things which came up every once in a while:

1. option to slave channels to a 'master channel' ( -- > global settings --> TR1 master: yes). enabling this option will make the channels try to resync with a/the master channel (= channel with smallest divider/multiplier) whenever the multiplier changes. that's to make sure divisions don't get out of sync, as the channels are normally independent. (resync happens when the master channel resets, so the global sync behaviour will depend on the master divisor)

2. phase offset. can be used to swing/shuffle the clocks, sort of. technically, it just adds a cv-able phase offset (0% - 99% x period) -- as can be seen in the picture below (pink = external clock; yellow and light blue = channels 1, 2 multiplied x 2; dark blue = phase offset / modulation CV).




chances are this introduced some bugs ... let me know, if you can find any.
taichber
I've built yesterday a 2nd ornament & crime and 2 temps utile. o&c and one temps utile are working perfectily.
The second temps utile works and calibration was ok. Only problem is the buttom tactile button is not working.
I've hecked the switch with a DMM and reflowed all teensy and button solder joints. Stilll not working.

Does anyone know which teensy input is used for this button? Any other ideas what else to check?

Thanks!
taichber
taichber wrote:
I've built yesterday a 2nd ornament & crime and 2 temps utile. o&c and one temps utile are working perfectily.
The second temps utile works and calibration was ok. Only problem is the buttom tactile button is not working.
I've hecked the switch with a DMM and reflowed all teensy and button solder joints. Stilll not working.

Does anyone know which teensy input is used for this button? Any other ideas what else to check?

Thanks!


For the TU I have two different PCB revisions. I've built the latest firmware. The buttons with the 1.b PCB version are working. The bottom button of rev 1.c PCB is not working.

I've found in the TU_gpio.h two versions:

#define but_bot 4 and #define but_bot 12

Both defines do not work. Maybe is not a firmware issue but a solder flaw...
taichber
double post
mxmxmx
the lower button is pin 12; that one shouldn't cause any issues.

re defines, i've moved the switch to TU_options.h, but it's unlikely that you have to mess around with it; the boards in question haven't been available in a good while and they've never been available through any of the DIY shop/group buys/etc

also, fyi: this is the most up to date branch/code: https://github.com/mxmxmx/temps_utile-/tree/sync_variation
taichber
mxmxmx wrote:
the lower button is pin 12; that one shouldn't cause any issues.

re defines, i've moved the switch to TU_options.h, but it's unlikely that you have to mess around with it; the boards in question haven't been available in a good while and they've never been available through any of the DIY shop/group buys/etc

also, fyi: this is the most up to date branch/code: https://github.com/mxmxmx/temps_utile-/tree/sync_variation


Thanks. The firmware variation makes no difference. Should there be continuity between the 510R resistor and PIN 12 of the teensy?

Anything else I could check?
mxmxmx
taichber wrote:


Thanks. The firmware variation makes no difference. Should there be continuity between the 510R resistor and PIN 12 of the teensy?

Anything else I could check?


that bit is identical to o_C (see the schematic / here), so basically it's switch < 510R > pin 12; so there should be continuity between the one leg of the resistor and pin 12 ( = GPIO PTC7, not the physical pin 12).
taichber
mxmxmx wrote:
taichber wrote:


Thanks. The firmware variation makes no difference. Should there be continuity between the 510R resistor and PIN 12 of the teensy?

Anything else I could check?


that bit is identical to o_C (see the schematic / here), so basically it's switch < 510R > pin 12; so there should be continuity between the one leg of the resistor and pin 12 ( = GPIO PTC7, not the physical pin 12).


Somehow strange. I've just desoldered the 510R resistor and cleaned the pin of the button switch.
There is no continuity between the switch pin and 510R:



Maybe a faulty PCB? Bought it from grayscale. I bought the rev1.b directly from you.
taichber
taichber wrote:
mxmxmx wrote:
taichber wrote:


Thanks. The firmware variation makes no difference. Should there be continuity between the 510R resistor and PIN 12 of the teensy?

Anything else I could check?


that bit is identical to o_C (see the schematic / here), so basically it's switch < 510R > pin 12; so there should be continuity between the one leg of the resistor and pin 12 ( = GPIO PTC7, not the physical pin 12).


Somehow strange. I've just desoldered the 510R resistor and cleaned the pin of the button switch.
There is no continuity between the switch pin and 510R:



Maybe a faulty PCB? Bought it from grayscale. I bought the rev1.b directly from you.



It is working now screaming goo yo
Soldered a bridge with between the two joints. Either the PCB had a flaw or I broke something with the build yesterday. Anyway.
The module is great :-)
mxmxmx
taichber wrote:

Maybe a faulty PCB? Bought it from grayscale. I bought the rev1.b directly from you.


mmh, weird. possible, i guess, but haven't heard of those kind of issues before.
SlyFrank
I'm about to build a TU after building a few o_Cs, which all went fine.

Question: The Mouser most recent shopping cart for o_C swapped out the 22uF electrolytic caps for 27uF caps, due to Mouser being out of stock of the 22uF caps. The 27 uF caps work fine with o_C. I have 2x 27 uF caps left over - Can I also use them in my TU build? I'm assuming yes, but just checking to make sure...if not, I'm sure I can source 22 uF caps elsewhere.
mxmxmx
SlyFrank wrote:

Question: The Mouser most recent shopping cart for o_C swapped out the 22uF electrolytic caps for 27uF caps, due to Mouser being out of stock of the 22uF caps. The 27 uF caps work fine with o_C. I have 2x 27 uF caps left over - Can I also use them in my TU build? I'm assuming yes, but just checking to make sure...if not, I'm sure I can source 22 uF caps elsewhere.


yep, that'll be fine
SlyFrank
mxmxmx wrote:
someone requested "hotter" outputs from the DAC / output #D ... support for which i've now added to the firmware. specifically (to play nice with the calibration procedure), this expects the DAC to output -2V / 7.25V (default would be -4.5V/4.5V).

to try, you'd only have to change one resistor (3k9 --> 10k)


Does this change all outputs to 7.25V or only #D? Even if only #D I might want to do this for pinging filters, etc...debating before I start building...

As for recompiling (if I build it with the 10K), I assume I should do it like o_C, i.e. Arduino 1.8.1 and Teensyduino 1.35?

Edit: Rereading the original post I'm guessing it's #D only. Which, again, still might be worth doing.
basicbasic
Would it be possible for Temps to have an option where rather than divide an incoming clock it could apply an 'echo'? So for example, I have a trigger (probably into TR2) that happens very rarely but when it does I can get a set number of 'repeats' (which could be CV controllable) either synced (again CV modulatable!) or potentially even unsynced?

Apologies if this is already possible and i'm too dim to have worked it out hihi

(I realise it's probably doable already via some kind of AND logic but I reckon a specific mode for this could be useful, both for 'flam' type effects as well as just interesting patterns)
Sammus
Like a trigger repeat or ratcheting effect? Could be pretty sweet.
basicbasic
My initial thought was 'an echo for triggers - that would be fun' but I guess you could probably use it for ratcheting too. CV over number repeats and time would be a bonus.
flab
i found a yellow pcb, from the very first buy , i guess, can i still builded and be updated as the rest? i can not find sth at github, several printed valious are different. should i just buy a new one ?
mxmxmx
flab wrote:
i found a yellow pcb, from the very first buy , i guess, can i still builded and be updated as the rest? i can not find sth at github, several printed valious are different. should i just buy a new one ?


see here. they should work, though it'll make life easier getting a more recent version.
flab
Ok , thanks boss, I will get one from you then a bit later, thanks for your answer
SlyFrank
This is a noob question but here goes: I'm about to solder in the 10 uH inductor and I've never seen one like this before - my only experience is with through-hole inductors like on o_C. My instinct is to solder it in with the metal leads side down (on the board), but in the picture of a built TU it shows it with the metal leads face up. This seems counterintuitive to me as that would have a plastic-on-PCB connection - no metal from the inductor touching the pads on the PCB.

Is that a different part in that photo? Trying to avoid doing something dumb, i.e. soldering it in upside down d'oh!
basicbasic
Solder the metal tabs to the PCB. Not sure whats in the pic but most likely a different package or something.
SlyFrank
basicbasic wrote:
Solder the metal tabs to the PCB. Not sure whats in the pic but most likely a different package or something.


Thanks for the reply. That's what I figured, but in the build guide for TU the picture that represents a finished PCB shows a part in there that looks more like a resistor than what I have (I got mine from the BOM). Maybe some inductors are like that, but definitely not what I have.

Anyway, good-to-go now.

Cheers w00t
basicbasic
Some smaller value inductors do look almost exactly like resistors. The one I used in my Temps build was a small black package from memory. The also come as little 'spindles' with wire wrapped around them. I think it depends on the value required.
mxmxmx
SlyFrank wrote:

Anyway, good-to-go now.


what basicbasic said. i just used whatever i had. in this picture, you can see one of the little coil ones.

basicbasic wrote:
Would it be possible for Temps to have an option where rather than divide an incoming clock it could apply an 'echo'? So for example, I have a trigger (probably into TR2) that happens very rarely but when it does I can get a set number of 'repeats' (which could be CV controllable) either synced (again CV modulatable!) or potentially even unsynced?

Apologies if this is already possible and i'm too dim to have worked it out

(I realise it's probably doable already via some kind of AND logic but I reckon a specific mode for this could be useful, both for 'flam' type effects as well as just interesting patterns)


re echo: hadn't occurred to me, but something echo-like should be doable. not a proper delay line, of course, but something like repeat x many times. as things are, you could probably come up with a similar effect by muting the outputs with a second gate signal into TR2 (reset/mute = HI2, or LO2), but setting the repeats in firmware would be more convenient, i suppose, and allow for more options (like decaying intervals etc).
SlyFrank
mxmxmx wrote:
what basicbasic said. i just used whatever i had. in this picture, you can see one of the little coil ones.


Yup, that looks like exactly what I have. And it's been soldered in nicely.

Cheers Guinness ftw!
basicbasic
mxmxmx wrote:

re echo: hadn't occurred to me, but something echo-like should be doable. not a proper delay line, of course, but something like repeat x many times. as things are, you could probably come up with a similar effect by muting the outputs with a second gate signal into TR2 (reset/mute = HI2, or LO2), but setting the repeats in firmware would be more convenient, i suppose, and allow for more options (like decaying intervals etc).


Yeh exactly. I can think of a few ways to do it (mainly via logic) but a dedicated mode would be quite interesting especially if decay and div/mult were under DV control w00t
SlyFrank
Finished my TU build and I love it. But the DAC (#4) output yields not 9V PP, but 4.5V PP from +5V to +9.5V. Any idea what I might have done wrong? No big deal as the other 5 outputs work great, but would be nice to sort this out.
keninverse
mxmxmx wrote:

re echo: hadn't occurred to me, but something echo-like should be doable. not a proper delay line, of course, but something like repeat x many times. as things are, you could probably come up with a similar effect by muting the outputs with a second gate signal into TR2 (reset/mute = HI2, or LO2), but setting the repeats in firmware would be more convenient, i suppose, and allow for more options (like decaying intervals etc).


This would be great and easy way to divide up a step on a sequencer. I'd love to see this. I suppose there's a workaround though if you just used the sequencer app. Would it be possible to add the ability to modify pulse width for each step on the sequencer?
sempervirent
taichber wrote:
Somehow strange. I've just desoldered the 510R resistor and cleaned the pin of the button switch.
There is no continuity between the switch pin and 510R:

Maybe a faulty PCB? Bought it from grayscale. I bought the rev1.b directly from you.

I just checked the remaining TU v1.c PCBs that I have here, and they all have continuity between the points that you mention. I don't think the PCB was the problem.
mxmxmx
SlyFrank wrote:
Finished my TU build and I love it. But the DAC (#4) output yields not 9V PP, but 4.5V PP from +5V to +9.5V. Any idea what I might have done wrong? No big deal as the other 5 outputs work great, but would be nice to sort this out.


mmh, this is output #4 (not shown is the offset, which is injected via 3k9 resp 10k at C10/R44):




the first stage has a gain of ~ -1.75, the second one is ~ -1.67. the DAC output range is 3.3v, hence the full swing should be something like 9.5VPP.

how did you determine the output range? when calibrating the module?

either way, off my head i don't know what might cause this (wrong gain, wrong offset), except using incorrect resistor values. did you double check? (and sorry for the latency, i was on vacation)


keninverse wrote:
mxmxmx wrote:

re echo: hadn't occurred to me, but something echo-like should be doable. not a proper delay line, of course, but something like repeat x many times. as things are, you could probably come up with a similar effect by muting the outputs with a second gate signal into TR2 (reset/mute = HI2, or LO2), but setting the repeats in firmware would be more convenient, i suppose, and allow for more options (like decaying intervals etc).


This would be great and easy way to divide up a step on a sequencer. I'd love to see this. I suppose there's a workaround though if you just used the sequencer app. Would it be possible to add the ability to modify pulse width for each step on the sequencer?


pulsewidth per step would be doable, yes. in terms of UI, i guess it could be something like push-left-encoder/adjust-with-right-encoder. but i'm not sure what to do with the global (per channel) pulsewidth parameter in that case. i guess simply override it, if/once a step is modified?
Dark Barn
In Mult mode, (perhaps in others also,) at higher multiplication settings (x16 and higher iirc,) my TU is skipping pulses at regular intervals, possibly on the downbeats? When trouble shooting the issue I tried it with both internal and external clocking and both ways produced the same results.

Is this user error or a bug or an issue with my particular unit?
mxmxmx
Dark Barn wrote:
In Mult mode, (perhaps in others also,) at higher multiplication settings (x16 and higher iirc,) my TU is skipping pulses at regular intervals, possibly on the downbeats? When trouble shooting the issue I tried it with both internal and external clocking and both ways produced the same results.

Is this user error or a bug or an issue with my particular unit?


is that 1.2.2beta?

if so, i think that should be fixed in the current version: https://github.com/mxmxmx/temps_utile-
Dark Barn
Yes it was 1.2.2 beta. Thanks for the fix!
ratsnake
hiya, anyone have a recent mouser cart / project saved for the bom?
abozzelli
Anyone got a clue how the BURST mode in Temps Utile works? I'm trying to replicate the behaviour of the burst output on the Wogglebug. Setting the clock source to INT and playing with the various parameters (interval, spread, density) does nothing. Sometimes a single trigger is generated, but no burst.
lohacker
abozzelli wrote:
Anyone got a clue how the BURST mode in Temps Utile works? I'm trying to replicate the behaviour of the burst output on the Wogglebug. Setting the clock source to INT and playing with the various parameters (interval, spread, density) does nothing. Sometimes a single trigger is generated, but no burst.


I'm still exploring BURST mode too, however try with an higher mult setting (x4-x16) for more bursts
abozzelli
lohacker wrote:
I'm still exploring BURST mode too, however try with an higher mult setting (x4-x16) for more bursts


Already tried with no luck, I'm on the latest 1.2.2 beta seriously, i just don't get it
n0rd
Some feature requests please:

- Add more pulse width percent values other than just 50%. (Eg 10% to 90% or better 5% to 95%). Scrolling through 250ms in 1ms increments is tedious and these numbers only make sense when using x1).
- Add a "toggle output" mode. ie output goes high when it receives a input and stays high until next trigger. Maybe also LOGIC toggle too. ie op_1 = ch#1, op_2 = ch#2 and TR2 (or another ch#) toggles between them.
- If possible the ability to use one channel's output as a clock source to another channel. (Rather than just TR1, TR2 or INT). This would allow things like 3/2 (1.5) or 5/3 (1.667) etc.
- Inclusion of div/mult by 9, 10, 11, 13, 14, 15, ... (Maybe a new mode call "MULx" as to not clutter up "MULT" mode. Maybe another one called PRIM with prime numbers etc).

Thanks,
Steve
Funkydroid
Just received mine, someone else built. Which way the connector goes into the module. Red stripe with the white vertical stripe on the pcb? And red stripe is -12 right? hmmm.....
Sammus
Funkydroid wrote:
Just received mine, someone else built. Which way the connector goes into the module. Red stripe with the white vertical stripe on the pcb? And red stripe is -12 right? hmmm.....


Yes It's peanut butter jelly time!
Psy'low
Would it be possible to add extra divider in the MULT such as 128 , 256, 512?
aragorn23
Hi all. I'm getting a hex file too large error when I try update my TU via Teensy.

Any suggestions?
pld
aragorn23 wrote:
Hi all. I'm getting a hex file too large error when I try update my TU via Teensy.

Any suggestions?

You might need to load a different .hex first so the loader recognizes the Teensy. There's a link to one in the o_C instructions.
aragorn23
Ah, thanks pld :-)
lohacker
Could be possible to have more slots to save user presets? I like to have the default configuration when starting a patch, but I'd like to save complex states to recall later, many thanks for this module! thumbs up
pld
lohacker wrote:
Could be possible to have more slots to save user presets? I like to have the default configuration when starting a patch, but I'd like to save complex states to recall later, many thanks for this module! thumbs up

Yeah, slots for loading/saving states was one of the plans I had for o_C but it became unrealistic there...
TU suffers the same restriction of little easily usable non-volatile storage (2K), but assuming there's not a similar exponential app growth, it'd seem to be do-able (except devil, details, time, etc.)
paulg
Temps Utile is a great module! A must have I reckon. It's replaced 3 modules in my rack.

I'd love to see some kind of MI Grids / Noise Engineering Repetitor functionality on there. Is that doable with the hardware?
pld
paulg wrote:
I'd love to see some kind of MI Grids / Noise Engineering Repetitor functionality on there. Is that doable with the hardware?

Should be. There was mention of porting Grids to an app (much of the basic framework from o_C was re-used here, so apps should be supported) but there's a bit of effort required to extract the relevant parts, discard the AVR platform specifics, and come up with an IO/clock mapping and UI scheme...
paulg
pld gotcha. For what it's worth I think that'd be a very worthwhile addition cool
Rowan
Could anyone advise me as to how I would get my hands on a solder stencil for this?

I would like to try out DIY reflow soldering and this seems like a project to experiment with.

I've a got rev 1.b PCB
Altitude909
Rowan wrote:
Could anyone advise me as to how I would get my hands on a solder stencil for this?

I would like to try out DIY reflow soldering and this seems like a project to experiment with.

I've a got rev 1.b PCB


PCBway will make one for you from the gerbers. OSH park does as well
patchack
Hi all,
Any idea for a replacement of those 470nF capacitors (77-VJ0805Y474JXJTBC)? There's no stock on mouser. Does tolerance really matters ?
Thanks !
patchack
I found this one ref mouser 80-C0805C474J3R . I mingled nano and pico confused Now i have to check all my cart...
adh82
Hey gang, so I'm seeing a few different screens savers. Are there options to choose one?
Is there any development in the works for other screensavers?
Feeling like the screensaver could use more of the screen?
pld
adh82 wrote:
Hey gang, so I'm seeing a few different screens savers. Are there options to choose one?

That seems to mostly depend on the revision of the firmware, there's nothing obviously switchable in the code.

Quote:
Is there any development in the works for other screensavers?
Feeling like the screensaver could use more of the screen?

There's probably other stuff to show, but no idea what, if anything, is planned.
Of course someone will argue that it should show nothing to, well, save the screen smile For o_C at least the better nomenclature would have been along the lines of "visualization" but flying toasters, old habits, etc.
adh82
[quote="pld"]

Quote:

There's probably other stuff to show, but no idea what, if anything, is planned.
Of course someone will argue that it should show nothing to, well, save the screen smile For o_C at least the better nomenclature would have been along the lines of "visualization" but flying toasters, old habits, etc.


Visualisations are a much better choice.
And there should be more to show like:

- incoming clock and cv.
- loop length
- gate length
- timing gate pattern (currently visualised)
- star field generator the goes into hyper drive depending on clock/tempo
- some sweet 80's vertor graphic representation of all these things
- have the screen divided into 6 even sections

[|*_][|*_][|*_]
[|*_][|*_][|*_]

Just a few quick ideas.
Maybe bits of the quantimain could be used?
pld
Yep. The trick is designing simple ways of (usefully) representing the information within the constraints. But as they say, simple is not easy smile At say 42x64px per channel and the font being 6x8, eventually every pixel starts to count and even 1px spacings can add up...
adh82
Yeah absolutely, those pixels would add up pretty quickly.
I'm no good at coding yet but I'm not bad at design.
I might have a little play and see if I can knock up some ideas.
Hopefully they turn out well.
Llewspeed
Hi guys, I have a stupid question. When I divide a clock on the channel, the triggers don’t match with the first step. I suppose, I should use reset input, but have no success with my experiments. How to match all divided channels with first sequenser step?
bmoren
check out the global settings in the wiki: https://github.com/mxmxmx/temps_utile-/wiki/using-temps_utile#global-s ettings

"TR1 master: choose yes to sync all channels to a/the 'master' channel, this will help keeping the channels in sync (which are normally independent and may diverge, if/when clock divisions are manipulated)"
Llewspeed
bmoren wrote:
check out the global settings in the wiki: https://github.com/mxmxmx/temps_utile-/wiki/using-temps_utile#global-s ettings

"TR1 master: choose yes to sync all channels to a/the 'master' channel, this will help keeping the channels in sync (which are normally independent and may diverge, if/when clock divisions are manipulated)"

Thanks! It's peanut butter jelly time!
aragorn23
abozzelli wrote:
Anyone got a clue how the BURST mode in Temps Utile works? I'm trying to replicate the behaviour of the burst output on the Wogglebug. Setting the clock source to INT and playing with the various parameters (interval, spread, density) does nothing. Sometimes a single trigger is generated, but no burst.


Did you ever figure this out? I'm also struggling to reliably create bursts. Every now and then a burst will come through, but it seems almost random and unrelated to the settings...
abozzelli
aragorn23 wrote:
abozzelli wrote:
Anyone got a clue how the BURST mode in Temps Utile works? I'm trying to replicate the behaviour of the burst output on the Wogglebug. Setting the clock source to INT and playing with the various parameters (interval, spread, density) does nothing. Sometimes a single trigger is generated, but no burst.


Did you ever figure this out? I'm also struggling to reliably create bursts. Every now and then a burst will come through, but it seems almost random and unrelated to the settings...


Same here, sometime I get some burst but can't figure out how it works. I've sold the module at the end seriously, i just don't get it
adh82
Just wondering if there is anyway to delay triggers per channel?
Would love to add a little groove to some patterns
pld
adh82 wrote:
Just wondering if there is anyway to delay triggers per channel?
Would love to add a little groove to some patterns

There's the latency setting which is just a simple delay, and phase offset (see this post). Although honestly I haven't yet used any of them (nor the burst feature), so... smile
adh82
Cool thanks!
Ill check it out.

But one thing, I can't seem to find the phase or latency in all modes.
Should they be?

A simple trigger delay my milliseconds per channel would be amazing.
Is this a possibility in a future update? we're not worthy
pld
adh82 wrote:
Cool thanks!
Ill check it out.

But one thing, I can't seem to find the phase or latency in all modes.
Should they be?

The latency is in the CV page. Not sure about the phase TBH but it's possible it wasn't intended (or not added) for all modes.

Quote:
A simple trigger delay my milliseconds per channel would be amazing.
Is this a possibility in a future update? we're not worthy

The delay setting as-is gives a few fixed times. It'd probably be possible to write a more configurable way or with a finer granularity if/when updates happen.
adh82
Great, thanks for that.
I'll see if it can add the groove im after.

Hope you do get a chance to implement a finer delay control when you do the next update.
nimmen
Damn, forgot to unplug power cable before firmware flash(case was powered off), now my unit no longer responds or works in anyway, did I pretty much brick it? Is there any simpler way of fixing this?
nimmen
False alarm, after some tries with older firmware seems to be working now.
lohacker
Anyone noticed an irregular clock multiplication for values over 8x?
On mine it works fine for 1x, 2x, 3x, 4x, 5x, 6x, 7x and 8x but when using 12x and above I don't have a continuous stream of pulses but there are some regular interruptions. This happens both with ext. and int. clocks and with various pulse widths values. I've made a clip to show better this behaviour, sending an ext clock and multipling from 1x to 64x and back, out 1 is directly plugged in the mixer for monitoring.

lohacker
Self bump, anyone checked this? help

lohacker wrote:
Anyone noticed an irregular clock multiplication for values over 8x?
On mine it works fine for 1x, 2x, 3x, 4x, 5x, 6x, 7x and 8x but when using 12x and above I don't have a continuous stream of pulses but there are some regular interruptions. This happens both with ext. and int. clocks and with various pulse widths values. I've made a clip to show better this behaviour, sending an ext clock and multipling from 1x to 64x and back, out 1 is directly plugged in the mixer for monitoring.

n0rd
lohacker wrote:
anyone checked this? help

I just did I quick check... There is something not quite right going on with high multiplication values. I haven't put it through a scope to see but I can hear it. Seems to get worse with higher input rate or higher internal rate.

Eg with internal clock set to 120bpm it sounds ok until x24 and above.
However, with it set to 150bpm it sounds wrong after x12.

Updates/fixes on this seem to have stalled. (Beta since Aug '17).
Shame... there's potential in this module.

Steve
pld
lohacker wrote:
Anyone noticed an irregular clock multiplication for values over 8x?
On mine it works fine for 1x, 2x, 3x, 4x, 5x, 6x, 7x and 8x but when using 12x and above I don't have a continuous stream of pulses but there are some regular interruptions. This happens both with ext. and int. clocks and with various pulse widths values. I've made a clip to show better this behaviour, sending an ext clock and multipling from 1x to 64x and back, out 1 is directly plugged in the mixer for monitoring.

What are your "various" pulse width values and what bpm? It's just a shot in the dark, but without reading much of the code (and there's a few not-immediately-obvious things going on) a boundary case would be what happens when the duty cycle approaches (or tries to exceed) 100%. In n0rd's case, 120bpm x24 is ~21ms so the PW length would have to be smaller than that.
lohacker
pld wrote:
lohacker wrote:
Anyone noticed an irregular clock multiplication for values over 8x?
On mine it works fine for 1x, 2x, 3x, 4x, 5x, 6x, 7x and 8x but when using 12x and above I don't have a continuous stream of pulses but there are some regular interruptions. This happens both with ext. and int. clocks and with various pulse widths values. I've made a clip to show better this behaviour, sending an ext clock and multipling from 1x to 64x and back, out 1 is directly plugged in the mixer for monitoring.

What are your "various" pulse width values and what bpm? It's just a shot in the dark, but without reading much of the code (and there's a few not-immediately-obvious things going on) a boundary case would be what happens when the duty cycle approaches (or tries to exceed) 100%. In n0rd's case, 120bpm x24 is ~21ms so the PW length would have to be smaller than that.


Hi pld, yeah I know this and it's the first thing I thought too. Anyway I've tried with PW from 1ms over 100ms and also echo and 50% modes. BPM range around 80-120.
n0rd
I had PW set to 25ms when I tested before.

On the subject of PW, any chance of adding more pulse width percent values other than just 50%? (Eg 10% to 90% in 10% steps or better still, 5% to 95% in 5% steps).

Steve
pld
lohacker wrote:
Hi pld, yeah I know this and it's the first thing I thought too. Anyway I've tried with PW from 1ms over 100ms and also echo and 50% modes. BPM range around 80-120.

Oh well, it'd be too easy if it were something obvious smile

n0rd wrote:
On the subject of PW, any chance of adding more pulse width percent values other than just 50%? (Eg 10% to 90% in 10% steps or better still, 5% to 95% in 5% steps).

Probably. It kind of feels like one might then want a toggle between ms or % modes, but no idea how to make that useable.
mxmxmx
[quote="lohacker"]Self bump, anyone checked this? :help:

lohacker wrote:
Anyone noticed an irregular clock multiplication for values over 8x?
On mine it works fine for 1x, 2x, 3x, 4x, 5x, 6x, 7x and 8x but when using 12x and above I don't have a continuous stream of pulses but there are some regular interruptions. This happens both with ext. and int. clocks and with various pulse widths values. I've made a clip to show better this behaviour, sending an ext clock and multipling from 1x to 64x and back, out 1 is directly plugged in the mixer for monitoring.


IIRC that should have been fixed here: https://github.com/mxmxmx/temps_utile-/commit/19ca8389655879c600cba2a4 4565d2928f97bbf9

and sorry, haven't been checking in here for a while ...
lohacker
mxmxmx wrote:

IIRC that should have been fixed here: https://github.com/mxmxmx/temps_utile-/commit/19ca8389655879c600cba2a4 4565d2928f97bbf9

and sorry, haven't been checking in here for a while ...


Thanks as always mxmxmx, I thought it was strange this had gone unnoticed.
Looking forward to have it added in the next firmware release thumbs up
Sammus
lohacker wrote:
mxmxmx wrote:

IIRC that should have been fixed here: https://github.com/mxmxmx/temps_utile-/commit/19ca8389655879c600cba2a4 4565d2928f97bbf9

and sorry, haven't been checking in here for a while ...


Thanks as always mxmxmx, I thought it was strange this had gone unnoticed.
Looking forward to have it added in the next firmware release thumbs up


I think the point of mxmxmx post was that it was fixed 4 months that ago, just need to update smile
lohacker
Sammus wrote:
lohacker wrote:
mxmxmx wrote:

IIRC that should have been fixed here: https://github.com/mxmxmx/temps_utile-/commit/19ca8389655879c600cba2a4 4565d2928f97bbf9

and sorry, haven't been checking in here for a while ...


Thanks as always mxmxmx, I thought it was strange this had gone unnoticed.
Looking forward to have it added in the next firmware release thumbs up


I think the point of mxmxmx post was that it was fixed 4 months that ago, just need to update smile


I know this, I mean added to the hex firmware
virtualcrimes
Is something like this possible with temps u? As I understand it, the ability to change the timing of one step to create phasing?
https://www.youtube.com/watch?v=nIeYg61ThWg
mxmxmx
virtualcrimes wrote:
Is something like this possible with temps u? As I understand it, the ability to change the timing of one step to create phasing?
https://www.youtube.com/watch?v=nIeYg61ThWg


not really, no (assuming you mean "can it clock 2 or more sequencers in ways that will result in such phasing"?).

in theory, you could hack the code to allow for fractional multipliers, say 1.0625 (if that's what the phasing is about), but to do that properly would really/ideally mean to redo the multiplication stuff (which is fairly messy and there's a few things going on that make sure the multiplied clock stays in sync with the incoming clock, and doesn't drift. as is, that only works with integers;
... but can be disabled easily, if you just wanted to try. basically here).

ditto for o_C, though IIRC Tim had added some divisors (/32, /31), which should/might work ... más o menos (i haven't tried)
Caseyjholmes
Thank you! Great module!!!
itsmeaflo
Nice! did you build this yourself? or does someone sell this premade?

Caseyjholmes wrote:
Thank you! Great module!!!
Caseyjholmes
Thanks! I built this one.
Really great module. It's running my whole system right now.
Ray Diode
Hi everyone, i recently took delivery of this amazingly
complex and fun module.
One thing, the clock outputs work wonderfully
but i can’t access the cv menus.
IE, the down button doesn’t work.
I’ve no DIY experience, but is this something I can easily fix?
Cheers all...
mxmxmx
Ray Diode wrote:
[...] the down button doesn’t work.
I’ve no DIY experience, but is this something I can easily fix?


yep, that should be something easy to fix. you'll need a soldering iron though. this is how the button is connected to the microcontroller:



double-check/reflow the lower switch and doublecheck the 510R resistor (the one that's turned 45 degrees).
Ray Diode
Fab!
Will invest in a soldering iron and sort it.
Thanks for the reply and kick-ass module.
basicbasic
Ray Diode wrote:
Fab!
Will invest in a soldering iron and sort it.
Thanks for the reply and kick-ass module.


I see you're in Aus - if you happen to be in Sydney i'd be happy to take a look at it. I've built two so am reasonably familiar with it.
autodafe
Just build mine.
worked 90% at first try
I get nothing out of Outs 1 and 4...should I check the TL074s ???
mxmxmx
autodafe wrote:
Just build mine.
worked 90% at first try
I get nothing out of Outs 1 and 4...should I check the TL074s ???


yep, check the TL074s + surrounding passives.

out 1 should be fairly straightforward (see here); that would be the one on the left, pins 5-7.

out 4 is slightly more involved (see here); that would be the TL074 on the right, pins 1-3, 5-7
autodafe
thx for your reply.I already reflowed both TL074 more than once, I need to check resistors and capacitors. i'll let you know
autodafe
yep! Out #1 was easy indeed. just reflowed some resistors around left TL074

Out #4 still doesn't work, even after reflowing its components. Will check again
Altitude909
autodafe wrote:
yep! Out #1 was easy indeed. just reflowed some resistors around left TL074

Out #4 still doesn't work, even after reflowing its components. Will check again


is the jumper installed? out 4 is the dac channel
Handmedown
I am not getting 5 volts to Teensy on rev 1.c board. Also not getting + 3.3 volts on 100 nf cap close to MCP 6004. I have not found voltage check list/picture for this but only for O_C which I am following. Any help would be appreciated. Thanks
Handmedown
Handmedown wrote:
I am not getting 5 volts to Teensy on rev 1.c board. Also not getting + 3.3 volts on 100 nf cap close to MCP 6004. I have not found voltage check list/picture for this but only for O_C which I am following. Any help would be appreciated. Thanks



got it sorted
autodafe
Altitude909 wrote:
autodafe wrote:
yep! Out #1 was easy indeed. just reflowed some resistors around left TL074

Out #4 still doesn't work, even after reflowing its components. Will check again


is the jumper installed? out 4 is the dac channel


yea, it was installed. It turned out it just needed calibration of the DAC, apparently...After calibration it seems to be working
Mirland
I've bought a TU - and it's fine and all. But the display is tilted a tad counter-clockwise. Not that it impairs the functionality but I cringe when I look at it. The display is just being hold in place by the plug in the top of it and it seems part of the tilt comes from the display being "flexible" due to this. Any ideas? Or should I just accept it?
flts
Mirland wrote:
I've bought a TU - and it's fine and all. But the display is tilted a tad counter-clockwise. Not that it impairs the functionality but I cringe when I look at it. The display is just being hold in place by the plug in the top of it and it seems part of the tilt comes from the display being "flexible" due to this. Any ideas? Or should I just accept it?


I think you bought that one from me and it's possible that it's just a tiny bit shoddy work in that respect, as it was originally built for my personal rack, and I'm generally bad at noting things like that seriously, i just don't get it I'm sorry.

FWIW, to be honest, I can't remember how the LCD is exactly mounted in that one (I've built three so far) but I'm pretty sure I didn't use the later recommended spacer as I didn't think of it at that point (https://github.com/mxmxmx/temps_utile-/wiki/build-it -> "if your OLED refuses to sit properly, a suitably sized spacer (~ 6mm) will help")

So that may be an option (remove the panel, install a plastic spacer, if you can't find one nicely I can send you one) if it's tilted in that particular direction. In any case, if you can send me some pics to remind me how it looks like, I can take a look...
Mirland
Sounds like you haha! Yeah, well I might just try to find a 6mm spacer and see it that does the trick. I know it's anal but when lined up with other modules...

We can move this to the PM section smile
0netwo0netwo
any videos on the modes/overview like the ones that there are for O+C??

and

is the logic mode like the Intellijel Plog??

thank you
DabiDabDab
Im loosing it a bit here with my uTemps build. DAC/4th/D out is stuck outputting 4.8V when i turn on the module before even going into calibration menu and doing the voltage stage calibrations - obviously it doesnt move when i start doing the calibration steps either. That is as well when no teensy is mounted in the socket. Also, physical measurements say that stuck 4.8V only appears on the pin 7 of the u12 (second amp section in the attached 072) directly before the jumper which ties with socket of the DAC/4th/D out . I dont see it on output or input (pin 1 and 2) of the first TL section of the u12 neither on the input of the second section of the u12 (pin 6) (these pins are all ground level = 0V), i see it only only on the output of the second section of the u12 . I have basically changed all but passives and electrolytics on the module by now. And also checked the values of resistors. I really cant see what could be of fault here. Any comment is greatly appreciated!

Thanx
DabiDabDab
Have tried it with 2 different tensies (3.2). Voltage reading off of the DAC/A14 pin is 1.8V. And i cant get any continuity between R47 and DAC out on teensie as schematics would make you believe. Can someone explain to me whats goin on?

Regards!
DabiDabDab
I guess hole under the dac pin and the pin should be connected? Meh
mattsb
0netwo0netwo wrote:
any videos on the modes/overview like the ones that there are for O+C??




Quote:
is the logic mode like the Intellijel Plog??


Kinda, in the context of logic operations that operate on itself. But nothing that takes external inputs.

Click me
0netwo0netwo
yeah ive seen that video but i meant more in depth that it goes through each app

can you please explain what you mean by the Intellijel Plog taking external inputs??
flts
0netwo0netwo wrote:
can you please explain what you mean by the Intellijel Plog taking external inputs??


The x, y and z on each channel of Plog are external logic (gate/trigger) inputs and out a & out b are the results of the logic operations applied to them (type selects the logic operation type, obviously). So you'll need to apply external gate/trigger voltages to the module to get anything out of it.

Contrary to that, Temps-Utile has logic modes that operate on the triggers generated by the module itself. So you can, say, choose output 3 to be derived from outputs 1 and 2 by some kind of logical operation - but you can't feed the module two or more external gate/trigger signals and perform logic on them.
0netwo0netwo
ahhh ok, so they're "internal" inputs with the temps utile module/software

why doesn't the temps utile use its trigger inputs for the logic, is it using them for something else??
mxmxmx
0netwo0netwo wrote:
ahhh ok, so they're "internal" inputs with the temps utile module/software

why doesn't the temps utile use its trigger inputs for the logic, is it using them for something else??


there's only two external inputs (TR1, TR2), mainly that's why.

you can slave, say, channel 1 to TR1, channel 2 to TR2, and have channel 3 do logic on channels 1+2. but typically/by default the six channels will be slaved to TR1. "logic" is simply another mode or algorithm, if you will, according to which a channel might generate its output. the signals are "internal" in the sense that the logic output is derived from the state of any (two) other channels; TU is a clock generator and it's not meant to replace a dedicated logic module such a Plog, though the logic mode will yield similar results, most of the time (and in this case has somewhat overlapping / advanced features, such as CV-control-of-logic-type and operand).
Altitude909
..
0netwo0netwo
mxmxmx wrote:
0netwo0netwo wrote:
ahhh ok, so they're "internal" inputs with the temps utile module/software

why doesn't the temps utile use its trigger inputs for the logic, is it using them for something else??


there's only two external inputs (TR1, TR2), mainly that's why.

you can slave, say, channel 1 to TR1, channel 2 to TR2, and have channel 3 do logic on channels 1+2. but typically/by default the six channels will be slaved to TR1. "logic" is simply another mode or algorithm, if you will, according to which a channel might generate its output. the signals are "internal" in the sense that the logic output is derived from the state of any (two) other channels; TU is a clock generator and it's not meant to replace a dedicated logic module such a Plog, though the logic mode will yield similar results, most of the time (and in this case has somewhat overlapping / advanced features, such as CV-control-of-logic-type and operand).



Thank You guys for your thorough explanation, much appreciated!
tdball
So I snagged a uTemps board that came with the SMD components soldered, after attaching the through hole components, it works fine over USB... But when I stick it in the case it only powers on if you plug the eurorack cable in AFTER the case boots up.

I'm using a trogotronic PSU, and it is the only module in my rack that exhibits this behavior. This sound familiar to anyone? I realize it may not be a module specific issue, but I've tried a different bus board, a different 10-16pin power cable, and verified the bus board spot works via a different module.

Any suggestions?
keninverse
Wait...works fine over USB? Did you cut the jumper on Vin and Vusb?
tdball
Yeah I've cut that.... however I'm unable to power it with eurorack power while flashing it, so I did solder back over it... As far as I was to understand, cutting it just kept myself from shooting myself in the foot when it came to having it powered via USB and eurorack.
mush
tdball wrote:
So I snagged a uTemps board that came with the SMD components soldered, after attaching the through hole components, it works fine over USB... But when I stick it in the case it only powers on if you plug the eurorack cable in AFTER the case boots up.

I'm using a trogotronic PSU, and it is the only module in my rack that exhibits this behavior. This sound familiar to anyone? I realize it may not be a module specific issue, but I've tried a different bus board, a different 10-16pin power cable, and verified the bus board spot works via a different module.

Any suggestions?


Sounds like the initial charging of capacitors of your modules is too much for your psu. The reason you only experience it on a digital module is because it won't boot without having sufficient power. The solution is usually a bigger psu... Or you can make a 'power delay':
https://www.cgs.synth.net/modules/cgs63_psd.html
Altitude909
tdball wrote:
So I snagged a uTemps board that came with the SMD components soldered, after attaching the through hole components, it works fine over USB... But when I stick it in the case it only powers on if you plug the eurorack cable in AFTER the case boots up.

I'm using a trogotronic PSU, and it is the only module in my rack that exhibits this behavior. This sound familiar to anyone? I realize it may not be a module specific issue, but I've tried a different bus board, a different 10-16pin power cable, and verified the bus board spot works via a different module.

Any suggestions?


This was addressed with the new revision of the board. Crappy power supplies have rails that come up at different rates and this locks up the teensy. The solution was to use a part called a voltage supervisor (MIC803) and a pogo pin, this keeps the teensy in reset until the voltage stabalizes. The files are in the uThings repo. You can probably bodge the parts on there but the reset pin is just a pad and it's underneath the teensy
tdball
mush wrote:
tdball wrote:
So I snagged a uTemps board that came with the SMD components soldered, after attaching the through hole components, it works fine over USB... But when I stick it in the case it only powers on if you plug the eurorack cable in AFTER the case boots up.

I'm using a trogotronic PSU, and it is the only module in my rack that exhibits this behavior. This sound familiar to anyone? I realize it may not be a module specific issue, but I've tried a different bus board, a different 10-16pin power cable, and verified the bus board spot works via a different module.

Any suggestions?


Sounds like the initial charging of capacitors of your modules is too much for your psu. The reason you only experience it on a digital module is because it won't boot without having sufficient power. The solution is usually a bigger psu... Or you can make a 'power delay':
https://www.cgs.synth.net/modules/cgs63_psd.html


Definitely could be, but this PSU is supposed to do something ridiculous like 10 amps. I have a uO_C right next to it and it boots fine. same power bus, same cable and everything. I'll give that a look.
tdball
Altitude909 wrote:
tdball wrote:
So I snagged a uTemps board that came with the SMD components soldered, after attaching the through hole components, it works fine over USB... But when I stick it in the case it only powers on if you plug the eurorack cable in AFTER the case boots up.

I'm using a trogotronic PSU, and it is the only module in my rack that exhibits this behavior. This sound familiar to anyone? I realize it may not be a module specific issue, but I've tried a different bus board, a different 10-16pin power cable, and verified the bus board spot works via a different module.

Any suggestions?


This was addressed with the new revision of the board. Crappy power supplies have rails that come up at different rates and this locks up the teensy. The solution was to use a part called a voltage supervisor (MIC803) and a pogo pin, this keeps the teensy in reset until the voltage stabalizes. The files are in the uThings repo. You can probably bodge the parts on there but the reset pin is just a pad and it's underneath the teensy


Ooooh, this looks interesting. uThings repo? I've checked the one for the uTemps, that's not the one you're mentioning though is it.... wouldn't happen to have a link to that would you?
Altitude909
https://github.com/jakplugg

It has nothing to do with the power of the PSU, its a specific issue with how fast the +/- rails come up. Some teensies are more prone than others it seems. It's weird that the OC works fine but the fact that hot plugging the temps fixes it confirms its that issue that youre seeing. We've seen this all over and is why there was a rev 1.1 for uOC and Temps
tdball
Altitude909 wrote:
https://github.com/jakplugg

It has nothing to do with the power of the PSU, its a specific issue with how fast the +/- rails come up. Some teensies are more prone than others it seems. It's weird that the OC works fine but the fact that hot plugging the temps fixes it confirms its that issue that youre seeing. We've seen this all over and is why there was a rev 1.1 for uOC and Temps


Thanks for the link. That's the one I'd checked but didn't catch anything about the pogo pin or the MIC803. I'm going to see if I can find out what revision I have. Much appreciated.

Here's a shot of the back of my board, I do have a hole, just in a different place. Picture file
Altitude909
^
Old rev.
tdball
Altitude909 wrote:
^
Old rev.

Sweeeeeet. Glad to know the problem is fixable. I didn't see it on the git repo or in a previous comment in the thread, was there any documentation about the pogo pin and the MIC803?
Altitude909
tdball wrote:
Altitude909 wrote:
^
Old rev.

Sweeeeeet. Glad to know the problem is fixable. I didn't see it on the git repo or in a previous comment in the thread, was there any documentation about the pogo pin and the MIC803?


You're right, still the old file. I'll talk to Jim to get them pushed out. Both revs are ready and tested so they are OK to release.
tdball
Altitude909 wrote:
tdball wrote:
Altitude909 wrote:
^
Old rev.

Sweeeeeet. Glad to know the problem is fixable. I didn't see it on the git repo or in a previous comment in the thread, was there any documentation about the pogo pin and the MIC803?


You're right, still the old file. I'll talk to Jim to get them pushed out. Both revs are ready and tested so they are OK to release.


You're awesome! I see the differences now between the newest revision and what I've got ( I actually have an unpopulated panel for revision 1.2 to compare against.)

Thanks for the help!
wardour
deleted
wavedepletion
Has anyone had any success with the Burst Generator mode? I've made a few attempts now at understanding how this works, but no matter what I try I can't seem to get it to output anything other than single random trigs/gates, and not very reliably.

I have firmware v1.2.3 installed.
Sammus
Missed the convo about non booting. To solve this I added a small cap on a jumper between teensy rst and ground. Need to remove jumper to flash, install jumper for use. Works perfectly.
gimber
Recently finished a uTemps with the grayscale PCB, and have a steady 9.5ish volts coming out of the DAC/out4. removing the jumper drops it to 0.
Reflowed the ICs which didn't help. Does anyone have any ideas where else I may have gone wrong to gave the output stuck like this?
Going through calibration, the output of 4 doesn't change with the different screens/settings.

Thanks in advance
mxmxmx
gimber wrote:
Recently finished a uTemps with the grayscale PCB, and have a steady 9.5ish volts coming out of the DAC/out4. removing the jumper drops it to 0.
Reflowed the ICs which didn't help. Does anyone have any ideas where else I may have gone wrong to gave the output stuck like this?
Going through calibration, the output of 4 doesn't change with the different screens/settings.


off my head, no. you'll have to poke around U12, if i see it right. might be easier to trace the signal from the DAC pin (A14) by outputting a sine or the like. here's a simple example, basically



// Simple DAC sine wave test on Teensy 3.x

float phase = 0.0;
float twopi = 3.14159 * 2;
elapsedMicros usec = 0;

void setup() {
analogWriteResolution(12);
}

void loop() {
float val = sin(phase) * 2000.0 + 2050.0;
analogWrite(A14, (int)val);
phase = phase + 0.02;
if (phase >= twopi) phase = 0;
while (usec < 500) ; // wait
usec = usec - 500;
}



wavedepletion wrote:
Has anyone had any success with the Burst Generator mode? I've made a few attempts now at understanding how this works, but no matter what I try I can't seem to get it to output anything other than single random trigs/gates, and not very reliably.

I have firmware v1.2.3 installed.


the idea is you have to trigger the burst with TR2 (TR1 provides the timing), but it ("burst mode") admittedly was a bit of a half-hearted (and semi-aborted) attempt; i guess it shouldn't even be in there. i have plans to fix it but didn't get round to do it
soundslikejoe
New user... clocking from DAW using ES-3 and Silent Way. The clock is tight if I got straight to sequencer or into a Time Wizard... but if I take the same clock (24ppqn) into Temps the sync is off... badly. All of the clocks will be the right tempo but they fire with latency (behind the beat). I assume it's a user error and some setting I've missed.

Quick tips?
mxmxmx
soundslikejoe wrote:
New user... clocking from DAW using ES-3 and Silent Way. The clock is tight if I got straight to sequencer or into a Time Wizard... but if I take the same clock (24ppqn) into Temps the sync is off... badly. All of the clocks will be the right tempo but they fire with latency (behind the beat). I assume it's a user error and some setting I've missed.

Quick tips?


what mode(s)? is this when using the global 24PPQ divider? are you multiplying? (if so see here, i wouldn't know how to solve this)
soundslikejoe
Yes... set global to 24PPQ and each channel is clocking to T1 input. DAW is sending 24PPQ. But... a few channels were set to multiply. Read link and it seems that might be tighter to send 4 or 8 PPQ and then divide for quarter notes. Eh?
mxmxmx
soundslikejoe wrote:
Yes... set global to 24PPQ and each channel is clocking to T1 input. DAW is sending 24PPQ. But... a few channels were set to multiply. Read link and it seems that might be tighter to send 4 or 8 PPQ and then divide for quarter notes. Eh?


... still not entirely sure what exactly the problem is that you're seeing, but yeah, generally speaking, if clocking the thing with 24/48/96 PPQ, it'll make sense to divide. the module updates at 16.67kHz or every 60 microseconds, so it'll be "tight" for most practical purposes; problems arise (or that's what the link is saying), once you start multiplying; the reason is that in order to figure the speed of the incoming clock, the module (or any such clock multiplier, i suppose) has to wait for (at least) one more clock signal. as things are, the relevant "clocks" are the quarter notes, so that's what's causing the phenomenon discussed in the linked github issue ("channel seems to wait until the next quarter note to start multiplying"). if that's what you're seeing ... i don't see a way around this, i'm afraid.
DJ_JITTER
I'm about to build both a uTemps and a uO_C using Grayscale PCBs. Am I right in thinking that this OPA2172IDR OP amp that's on the uO_C BOM will work fine with the uTemps?
mxmxmx
DJ_JITTER wrote:
Am I right in thinking that this OPA2172IDR OP amp that's on the uO_C BOM will work fine with the uTemps?


you mean as a substitute for the TL072s? sure, i suppose it would work ... but why not just use TL072?
DJ_JITTER
mxmxmx wrote:
DJ_JITTER wrote:
Am I right in thinking that this OPA2172IDR OP amp that's on the uO_C BOM will work fine with the uTemps?


you mean as a substitute for the TL072s? sure, i suppose it would work ... but why not just use TL072?


I was thinking of trying to streamline the Mouser order, but yeah it's not really worth it.

If anyone else is building both, I've combined the BOMs for both builds here. It's my first time having to find components rather than just buying a kit, so hopefully there's no major gaffes in there.
Supervillain
Hey,
I don't really get how RST1 and RST2 work...
What's the difference with low/hi setting?
mxmxmx
Supervillain wrote:
Hey,
I don't really get how RST1 and RST2 work...
What's the difference with low/hi setting?


from the manual:

Quote:
reset/mute: when applicable, this assigns a reset source (basically: MULT, EUCLID, SEQ); it typically doesn't make sense, of course, to choose RST1 when the clock source is TR1, and v.v. Alternatively, choose =LO2 or =HI2 to mute a/the channel whenever TR2 goes low, respectively high.


in other words: RST1 = reset via TR1; RST2 = reset via TR2, LO2 = mute/pause channel while TR2 is low; HI2 = mute/pause while TR2 is high. so HI2/LO2 isn't about reset at all, but "gating" the channels. that's the difference. makes sense?
Supervillain
Thanks for clarifying this point, now I got it!
tillibilli
Hey there,
I just finished a micro tempsutile. Everything seems to be working nicely, but the DAC Out 4.
Without a Jumper installed it works like the other pins. But with the Jumper in one position it gives out a straight 10V all the time, and with the jumper in the other positions it gives out something like -9.9V straight... Anybody knows what could be wrong?

Thanks!
mxmxmx
tillibilli wrote:
Hey there,
I just finished a micro tempsutile. Everything seems to be working nicely, but the DAC Out 4.
Without a Jumper installed it works like the other pins. But with the Jumper in one position it gives out a straight 10V all the time, and with the jumper in the other positions it gives out something like -9.9V straight... Anybody knows what could be wrong?

Thanks!


hi

the jumper is really a vestige from when there were teensy 3.0s, which didn't come with a DAC. only the "DAC" position is supported by the firmware, so don't bother with the other one.

as for what might be wrong ... hard to tell. as a first step, double-check the output-stage for lose solder points, shorts etc; the schematic can be found here: https://github.com/jakplugg/T_u
pld
So a thing happened...


Short description:
- The app menu (still invoked by long-press R) now has four pages. L selects the page.
- Settings from the global config app are in the Conf page.
- You can get back to the current app with Down or pressing R to select an entry in the Apps page (still only one app though).
- Long-pressing R on an/the entry in Apps will reset to defaults.
- Load and Save from/to a slot are activated by long-pressing R also (cursor will flash).
- A slot contains all the user patterns and the global config settings...
- ...but only saves the parameters for the currently active mode in each channel (with minor exceptions); other modes are reset to defaults on load. That was a prerequisite to getting four slots.
- It should be fairly resilient (the slots may display garbled text at worst, but not try to load garbage) but it's probably a Good Idea to reset the eeprom once at startup (hold Up + Down).
- Existing settings are ignored, and lost on save.
- Calibration should be untouched.
- Module boots to last used slot.

Code here
No .hex since it's intentionally an early adopter preview and it's a dev branch so no guarantees of not being rebased, etc.
I've only compiled it using Arduino 1.8.2.

Answers to FAQs:
Yes. No. Maybe. It depends.
smile

P.S. if anyone has a spare ut_U or 1U PCB/panel... hint hint.
lohacker
Great news! I was waiting for saving slots for a long time, can't wait to try it asap w00t thumbs up It's peanut butter jelly time!
timmmofa
this is amazing!
Bamboombaps
I'm having some issues calibrating - the -4, -2, 0, 2 are all good , the +4 was tricky but close enough but now moving on to the CV 1 from the DAC output there's no change from like 10v then all of a sudden it's -4 and I can't get to 0v

On the CV2 screen the value on the calibration is flickering between two numbers which doesn't seem right...
mxmxmx
Bamboombaps wrote:
I'm having some issues calibrating - the -4, -2, 0, 2 are all good , the +4 was tricky but close enough but now moving on to the CV 1 from the DAC output there's no change from like 10v then all of a sudden it's -4 and I can't get to 0v

On the CV2 screen the value on the calibration is flickering between two numbers which doesn't seem right...


if there's no change, something isn't right. the input stage is fairly simple/straightforward, i'd start with reflowing the passives around the MCP6004 (or 6002 if building the "u" version.)

as for the flickering, this is what the instructions say:

Quote:
There may be some jitter and it might jump around between -1 and 0, or between 0 and 1 - that's fine - just get it as close to zero as possible. when done, click to proceed and repeat for the remaining CV inputs.


if the jitter is worse, then it may not be right. hard to tell.

re DAC / 4V: which PCB is that? "u"? or regular? if the latter, one thing you might want to try is replacing the one 3k9 resistor with 4k2 (that's R54 in the "u"-Version), that might/should help; also see here.
Bamboombaps
Thanks I'll try a reflow

The jitter I'm seeing isn't on the dmm it's on the screen of the module itself, on the value that is adjusted by the right encoder. Is this the same jitter?

It's a regular 1b oard btw - if I change that 3k9 to a 4k2 dies the firmware need recompiling?
mxmxmx
Bamboombaps wrote:

The jitter I'm seeing isn't on the dmm it's on the screen of the module itself, on the value that is adjusted by the right encoder. Is this the same jitter?


the 'jitter' referred to in the how-to is what you'd see on the screen of the module during calibration of the CV inputs ("twist the right encoder so that the value shown is as close to 0 as possible.")

Bamboombaps wrote:

It's a regular 1b oard btw - if I change that 3k9 to a 4k2 dies the firmware need recompiling?


no, only when using 10k (in which case the range will be offset more drastically (to -2V / +7V); in that case uncomment the #define MOD_OFFSET switch in TU_options.h)
mxmxmx
fwiw/fyi, i contracted a flu, so i got to play around a bit with the largely dysfunctional 'burst' mode. here's a hopefully more useful version now, some sort of simple one-shot pulse train generator:

https://github.com/mxmxmx/temps_utile-/tree/1.3test

there might still be some bugs (...), but the basics seem to work pretty ok. 'burst' comes with three parameters:

density: amount of clocks per burst (1-31)
initial frequency (in %): to fine-tune the burst frequency/damping (interacts with the divisor/multiplier)
damping: controls the, well, damping (values > 1 : decaying, values < 1 : decelerating)

the 'burst' frequency is controlled, basically, by either the external clock (when choosing clk src = TR1 or TR2), or the internal BPM clock. the other clock input is used to actually trigger a burst; when using the internal clock, there's a choice between TR1 or TR2 (burst src). bursts can also be delayed using the 'phase' parameter.
keninverse
Brilliant. Thank you!
lohacker
Wow, the burst mode now is a gem and the save/load slots are a great addition! Thanks thumbs up
mxmxmx
lohacker wrote:
Wow, the burst mode now is a gem and the save/load slots are a great addition! Thanks



cool ...

NB: anyone updating the firmware: it might make sense to clear the EEPROM after doing so (= push both the up and down buttons during start-up), the storage stuff has been restructured quite a bit, so chances are you'll see garbled mess rather than empty slots. (clearing the EEPROM won't affect the calibration data, just the saved settings, if any).

i've uploaded the .hex in the meantime: https://github.com/mxmxmx/temps_utile-/releases ; plus updated the manual.
justin3am
Thanks so much! Great update!
FrJK
Hi, I habe a strange behaviour with a uTemps.
It is running fine except 1 thing.
When I have it in Mult mode and set the divider to 24 it does not start clocking after boot. All other channel work fine.
If I enter into the menu and change div to another value and then back to 24, all is good.
I changed to another channel, same behaviour.
Based on my observations this does only happen with div 24 ...
Any one any idea?

I updated to 1.30 but no change.

Thanks, Frank.
mxmxmx
FrJK wrote:

I changed to another channel, same behaviour.
Based on my observations this does only happen with div 24 ...
Any one any idea?


seems to happen with any divisor > 16. not sure why that is, but here's a temporary fix
FrJK
Quote:
seems to happen with any divisor > 16. not sure why that is, but here's a temporary fix


Great, thanks. Will you provide an updated hex file in the next few days?
mxmxmx
FrJK wrote:

Great, thanks. Will you provide an updated hex file in the next few days?


sure ... i don't think this warrants a new release; for your convenience, i've discretely replaced the hex here.
FrJK
Quote:
sure ... i don't think this warrants a new release; for your convenience, i've discretely replaced the hex here.


Great (start up problem is solved) and thanks a lot for the very quick help.
duno
Am I ok to use 1/8w instead of 1/4w for the resistors on this? Working through the bom, cant seem to find the 6.4k anywhere for a couple of months.
mxmxmx
duno wrote:
Am I ok to use 1/8w instead of 1/4w for the resistors on this? Working through the bom, cant seem to find the 6.4k anywhere for a couple of months.


i'd assume yes. alternatively, use 0603 or 0805 6k81 ones ? (it's 6k8, not 6k4)
duno
mxmxmx wrote:
duno wrote:
Am I ok to use 1/8w instead of 1/4w for the resistors on this? Working through the bom, cant seem to find the 6.4k anywhere for a couple of months.


i'd assume yes. alternatively, use 0603 or 0805 6k81 ones ? (it's 6k8, not 6k4)


Thanks
mutronic
I recently got an oshpark teensy 3.2 to fit into a mini temps I'm building, and in the process of troubleshooting the module in trying to get it to turn on, I attempted to replace the teensy board in my own personal mini temps utile with the osh park one I ordered. I took the module out of my mantis, and replaced the teensy. When I plugged everything back in, and turned the module on, my R60 resistor exploded and since then have been unable to get the module working (even after replacing the resistor, diode, and LM4040 regulator). Sort of stumped as to what could be preventing it from powering on. Gonna keep on keepin on, but am open to suggestions as to why this might be happening!
mxmxmx
mutronic wrote:
I recently got an oshpark teensy 3.2 to fit into a mini temps I'm building, and in the process of troubleshooting the module in trying to get it to turn on, I attempted to replace the teensy board in my own personal mini temps utile with the osh park one I ordered. I took the module out of my mantis, and replaced the teensy. When I plugged everything back in, and turned the module on, my R60 resistor exploded and since then have been unable to get the module working (even after replacing the resistor, diode, and LM4040 regulator). Sort of stumped as to what could be preventing it from powering on. Gonna keep on keepin on, but am open to suggestions as to why this might be happening!


so you made your (previously working?) module blow up just putting in a new dev board? that's weird.

either way, it should be easy/possible to get the power section back up and running, it's really just the few parts around the LM1117-5 (the LM4040 isn't about power). have you measured the LM1117 output? w/o teensy, that is.
midirobot
Hello : )

the slot saving is great !
would ask if possible to implement for ch.4 in dac mode have more choice for clock source ? (others channel for example ).
and a 3-2-1 step for the LSFR lenght would be great ^^
mutronic
mxmxmx wrote:
mutronic wrote:
I recently got an oshpark teensy 3.2 to fit into a mini temps I'm building, and in the process of troubleshooting the module in trying to get it to turn on, I attempted to replace the teensy board in my own personal mini temps utile with the osh park one I ordered. I took the module out of my mantis, and replaced the teensy. When I plugged everything back in, and turned the module on, my R60 resistor exploded and since then have been unable to get the module working (even after replacing the resistor, diode, and LM4040 regulator). Sort of stumped as to what could be preventing it from powering on. Gonna keep on keepin on, but am open to suggestions as to why this might be happening!


so you made your (previously working?) module blow up just putting in a new dev board? that's weird.

either way, it should be easy/possible to get the power section back up and running, it's really just the few parts around the LM1117-5 (the LM4040 isn't about power). have you measured the LM1117 output? w/o teensy, that is.


Yeah it worked for over a year. I'll measure the output and see what I get.
DJ_JITTER
I've just built a micro Temps, everything seems to be functioning properly except for the DAC output. I can only get the 4V calibration up to 2.8V with it set to full. The rest of the calibration points are fine, and it does output as expected, just at the 2.8v ceiling rather than 4V. Any ideas?
mxmxmx
DJ_JITTER wrote:
I've just built a micro Temps, everything seems to be functioning properly except for the DAC output. I can only get the 4V calibration up to 2.8V with it set to full. The rest of the calibration points are fine, and it does output as expected, just at the 2.8v ceiling rather than 4V. Any ideas?


so you can calibrate -4V, -2V, 0V, +2V, but not +4V ? could be the offset, or are the calibration points (the ones that work) fairly off vis-à-vis the default values? what's the lowest you can go? it shouldn't go much below -4.5V, off the top of my head
DJ_JITTER
The minimum I can get out of it (calibrated to an offset of 0) seems to be -6.6v, and the max is 2.8v (calibrated to an offset of 4095).

Here's a table with what was being output at the default calibration levels, and what I needed to set them to to get the required voltages:

Test Point (V) __Default Offset __ Output at default (V) __Offset required

-4 ____________514 ___________-5.37 _________________1094

-2 ____________1375 __________-3.33 _________________1940

0 _____________2236__________-1.30 _________________2790

2 _____________3097 __________0.72 _________________3635

4 _____________3960 __________2.76 __________________N/A
mxmxmx
gain looks ok and it's ~2V steps, so i'd say it's just the offset, assuming the line below reads -1.30V, not +1.30V:


DJ_JITTER wrote:


0 _____________2236___________1.30 _________________2790



is this the 8HP version or 14HP or ... ? if the former, double-check the value of R54; if the latter, also double-check that resistors: details see here.
DJ_JITTER
Ah yeah, that's supposed to be a negative.

It's an 8HP version. I'm getting 4.14 kOhm on R54, which is supposed to be 4.2K in the 8HP right?
mxmxmx
DJ_JITTER wrote:
Ah yeah, that's supposed to be a negative.

It's an 8HP version. I'm getting 4.14 kOhm on R54, which is supposed to be 4.2K in the 8HP right?


yep, that's the one. 4.14k vs 4.2k wouldn't matter though. what happens if you entirely remove it? (what should happen: 0v ... 9.5v at the output)
DJ_JITTER
Yep, removing R54 results in the output ranging from 0v to 9.5v
terje_t
Hey all,

I’m having an issue with a Temps Utile I just built. It generally works fine, calibration went fine. It’s just that sometimes the module doesn’t turn on when I power on my case. When this happens, I power off the case again, and when I power it back on the Temps Utile never fails to turn on.

Anyone recognize this behaviour and know what the problem might be?

It was built from a 8hp Magpie Modular PCB. I have not cut the power trace on the Teensy, because it’s easier for me to take the module out of the case to update it.

Thanks!
mxmxmx
DJ_JITTER wrote:
Yep, removing R54 results in the output ranging from 0v to 9.5v


mmh, that's good. weird though about the 4k2 resistor. you're 100% about the value?

either way, in theory you could just keep it this way (0-9.5v) (it would need some minor adjustment to the code, to make the gate go down all the way to 0v; that's basically already in there though, because of the buchla-format "2TT"). or if you have a 10k resistor, you may want to try this and recompile with #define MOD_OFFSET ? it doesn't matter much otherwise, the offset is mainly a matter of taste/preference i suppose

terje_t wrote:
Hey all,

I’m having an issue with a Temps Utile I just built. It generally works fine, calibration went fine. It’s just that sometimes the module doesn’t turn on when I power on my case. When this happens, I power off the case again, and when I power it back on the Temps Utile never fails to turn on.

Anyone recognize this behaviour and know what the problem might be?

It was built from a 8hp Magpie Modular PCB. I have not cut the power trace on the Teensy, because it’s easier for me to take the module out of the case to update it.

Thanks!


which PSU is that? ... anyways, yes, people occasionally seem to be running into boot issues in combination with certain PSUs (see further upthread.)

re 8HP: AFAIK, there's two versions of the board, one with a MIC803 (IC U4), which should/would solve it, and an earlier one without. you probably have the older one?
terje_t
mxmxmx wrote:

which PSU is that? ... anyways, yes, people occasionally seem to be running into boot issues in combination with certain PSUs (see further upthread.)

re 8HP: AFAIK, there's two versions of the board, one with a MIC803 (IC U4), which should/would solve it, and an earlier one without. you probably have the older one?


Right, yep - no MIC803 on this one so that’s probably it. I saw the stuff about the boot issues but didn’t connect it to my problem for some reason. Thanks!

My case is the Doepfer LC9 with PSU3.

It’s not a big deal, since I know it comes on the second time.
mxmxmx
terje_t wrote:

Right, yep - no MIC803 on this one so that’s probably it. I saw the stuff about the boot issues but didn’t connect it to my problem for some reason. Thanks!

My case is the Doepfer LC9 with PSU3.

It’s not a big deal, since I know it comes on the second time.


mmh, i see. if it really bothers you, a possible hack is to solder the MIC803 onto the gnd and 3v3 pads on the bottom side:



you'd then need to jumper the MIC803 "RST" pin to the RST test point with a thin wire, and also solder a pull-up resistor (100k) across 3v3 and reset
terje_t
Thanks for the tip! I’ll consider it smile
Sammus
Much easier fix for this is to just add a small cap between rst and gnd on teensy. I think I used like 10pf or 100pf. This holds reset low for a fraction of a second and you get 100% boot.

The issue is that teensy then won't reset for flashing - so I stuck one pin of a 2pin header into the empty gnd pin on teensy, and ran the cap from the other leg to the rst pad. Then jumper on the header for use, jumper removed for upgrade.
mutronic
can you only compile temps_utile firmware in linux? I try to flash it using the teensy app and it tells me the hex file is too large.
mutronic
I plugged in this micro temps one evening and the 4.7 resistor blew, and I'm pretty sure it's because the corner screw shorted out the diode when I plugged it in. I soldered on a new resistor, 1117, and diode onto the board, and I can't get any power past 2.5v. I figured more eyes is better than two, so am open to criticisms or suggestions.

mxmxmx
@mutronic: no, the process should be fairly agnostic re OS. try to upload a/the "blink" example sketch first, the loader app probably thinks you're trying to flash a teensy 3.0


not sure why a LM1117 would output 2.5V (unless it's the 2.5V version...). can't spot anything, but then I'm on my phone..
consumer
I just came here to post a thank you to mxmxmx for a nice project: I just built up a rev1-c board (fabbed a couple years ago) and everything went swimmingly the first time through after following the github wiki.

I notice that this is the second time I'm posting here just next to Mutronic about an mxmxmx project: A nice coincidence, although I imagine with my glacial pace at these projects that he's finished six since I last posted. In any event:

Thank you, mxmxmx for this super-cool project.
terje_t
Heh, this is probably a long shot but on the chance someone's done the same dumb thing as me with the same result:

My Temps Utile used to have a 3D-printed plastic front panel. I recently milled an aluminium panel and excitedly swapped out the plastic one. You can imagine where this is going. The pins from the display was touching the now grounded front panel.

It showed a half strange kind of frozen startup screen a couple times until I figured out what was wrong and isolated it. Unfortunately, the module has now stopped working.

The thing is: it works on USB power but not on power from my rack. I have tested both display and outputs on USB power: all is good. On rack power, the display doesn't come on and the outputs are dead.

On USB power, I can see the LED on the Teensy light up. This does not happen on rack power. However, all the quick points I can think to check seem allright - 5V out of one voltage converter, 3.3V out of the other, and I see 3.3V on pins Vin and 3.3 on the Teensy.

Any ideas?
n0rd
Bug v1.3.1b: Adjusting "Phase %" on long divisions causes incorrect output.

Eg
mode: MULT
mult/div: /4 (or bigger)
pulsewidth: 50% (can also occur when set to ms too).
clock src: INIT (120bpm)**

At "phase % = 0", output is ok but adjusting "phase %" to 3 or more output is incorrect. (**Note: When using a external input (eg TR1), "phase %" works ok until higher value ~8 or 10).

Request:
Additional "pulsewidth" sizes other than just 50%. (Eg 5% to 95% in 5% steps).

Steve
mxmxmx
n0rd wrote:
Bug v1.3.1b: Adjusting "Phase %" on long divisions causes incorrect output.


incorrect meaning ... the phase is/seems off? or missing triggers?

if the former (i assume...), chances are the channels are out of sync, it's really 6 independent channels ... what happens when you push the left encoder (= manual sync)?

with TR1 it should work when doing: long press R > Conf > TR Master "yes". i suppose something similar might work for the internal clock, too ... let's see. that will tend to fall into the "refactoring" category, i'm afraid

@terje_t

the VIN pin should read 5V, so sounds as if something isn't right with the LM1117?
n0rd
mxmxmx wrote:
n0rd wrote:
Bug v1.3.1b: Adjusting "Phase %" on long divisions causes incorrect output.


incorrect meaning ... the phase is/seems off? or missing triggers?


It's missing triggers. Output goes high and can act like a toggle when it should just be changing phase. Given it only seems to happen with large divisions it might just be a overflow of a variable.
ricwadsworth
Just built my first TU and very pleased with it. All is working fine except that when testing the output voltage on channel 1 is ~3.3v not the ~10v the others give (channel 4 gives me the ~4.7v too)

Also I've just noticed that all CV values from the debug menu are 1024 not 2048.

The unit seems to function fine but would nice to have it set as it should be in the docs.

Any ideas what the issue could be?
terje_t
mxmxmx wrote:

@terje_t

the VIN pin should read 5V, so sounds as if something isn't right with the LM1117?


Oops, my bad - the VIN - pin 1, on the Teensy reads close to 5V (4.9ish). Thanks for the reply.

I have since tried flashing another Teensy I had with the Temps Utile firmware, with no more luck. So that might mean the Teensy is ok and the problem is on the main PCB. It did not have the DAC pin soldered to anything but I would imagine I'd see the screen coming on anyway?
mxmxmx
n0rd wrote:
mxmxmx wrote:
n0rd wrote:
Bug v1.3.1b: Adjusting "Phase %" on long divisions causes incorrect output.


incorrect meaning ... the phase is/seems off? or missing triggers?


It's missing triggers.


mmh, it seems to be working here (*). the phase stuff doesn't behave ideally though when changing the multiplier/divisor, working on it ...

* using this branch: https://github.com/mxmxmx/temps_utile-/tree/1.3b ...

terje_t wrote:
mxmxmx wrote:

@terje_t

the VIN pin should read 5V, so sounds as if something isn't right with the LM1117?


Oops, my bad - the VIN - pin 1, on the Teensy reads close to 5V (4.9ish). Thanks for the reply.

I have since tried flashing another Teensy I had with the Temps Utile firmware, with no more luck. So that might mean the Teensy is ok and the problem is on the main PCB. It did not have the DAC pin soldered to anything but I would imagine I'd see the screen coming on anyway?


yeah, the display is entirely agnostic about the DAC. so it comes on with USB, but not from the PSU? sounds like boot-up problems (weird though that it should have worked before?). see the MIC803 etc discussion further upthread ...
n0rd
mxmxmx wrote:
n0rd wrote:
Bug v1.3.1b: Adjusting "Phase %" on long divisions causes incorrect output.


mmh, it seems to be working here (*). the phase stuff doesn't behave ideally though when changing the multiplier/divisor, working on it ...

* using this branch: https://github.com/mxmxmx/temps_utile-/tree/1.3b ...


Just did a test of 1.3.2.b.

Adjusting "phase %" manually occasionally seems to cause the output to disable (stay low) for a cycle. (Wiggle knob whilst adjusting "phase %" to reproduce. Note it seems to occur more with high divisions like /8).

Using "pulsewidth 50%" with "phase %" > ~50 doesn't work correctly. Output seems to go back to triggers and sometimes just stays high.

Resetting a stage (ie RST2) with "phase %" non zero also seems to mess with the output (stays high). Adjust "phase %" back to zero seems to correct it.
ricwadsworth
ricwadsworth wrote:
Just built my first TU and very pleased with it. All is working fine except that when testing the output voltage on channel 1 is ~3.3v not the ~10v the others give (channel 4 gives me the ~4.7v too)

Also I've just noticed that all CV values from the debug menu are 1024 not 2048.

The unit seems to function fine but would nice to have it set as it should be in the docs.

Any ideas what the issue could be?


Just to say a look at the schematics and reflow of the 10k and 20k resistors in the CV1 circuit sorted the ~3.3v issue.

All CVs still show 1024 in the debug so if there are any suggestions as to why that might be it would be great.
djthopa
Apologies if this has been asked.

My temps panel does not come with a hole on the right of the lcd like on the ornament and crimes.

When i push the top button, i can see the lcd bending down Dead Banana

Any ideas on how to fix this?

There is s space behind the panel but i cant bolt it to the panel since there is no hole.

Cheers
ricwadsworth
djthopa wrote:
Apologies if this has been asked.

My temps panel does not come with a hole on the right of the lcd like on the ornament and crimes.

When i push the top button, i can see the lcd bending down Dead Banana

Any ideas on how to fix this?

There is s space behind the panel but i cant bolt it to the panel since there is no hole.

Cheers


I used a similar spacer to the o_C but reverse attached through the PCB.
Hope this helps.

djthopa
ricwadsworth wrote:
djthopa wrote:
Apologies if this has been asked.

My temps panel does not come with a hole on the right of the lcd like on the ornament and crimes.

When i push the top button, i can see the lcd bending down Dead Banana

Any ideas on how to fix this?

There is s space behind the panel but i cant bolt it to the panel since there is no hole.

Cheers


I used a similar spacer to the o_C but reverse attached through the PCB.
Hope this helps.



Thanks for the heads up! I was thinking on using some hot glue between the spacer and the pcb.

Ill give your idea a go, i dont fancy drilling the panel.

Edited:im looking closer the image you attached, but that does not stop the pcb from pushing away from the panel when pressing the button, or am i missing something?

Cheers!
ricwadsworth
Quote:


Thanks for the heads up! I was thinking on using some hot glue between the spacer and the pcb.

Ill give your idea a go, i dont fancy drilling the panel.

Edited:im looking closer the image you attached, but that does not stop the pcb from pushing away from the panel when pressing the button, or am i missing something?

Cheers!


I see what you mean. Mine was to give clearance for the oled. Maybe a dot of hot glue?. I think I might try that on mine too smile
MUFF WIGGLER Forum Index -> Music Tech DIY  
Page 1 of 31
Powered by phpBB © phpBB Group