br>Just received the board in the post, thanks a lot! Do you happen to have a mouser cart for it? Thanks br> br>

br>flts

br>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. br> br>

br>midirobot

br>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 br> br>

br>mxmxmx

br>

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).

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). br> br>

br>midirobot

br>great max the one you linked deliver to Italia:)

thanks br> br>

br>mxmxmx

br>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) br> br>

br>flts

br>^- 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. br> br>

br>pld

br>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

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 But I've measured pulses on the outputs with a clock input so looks good. br> br>

br>lamouette/rck

br>No clock multiplier ? only diviser ? br> br>

br>mush

br>

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... br> br>

br>mxmxmx

br>

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. br> br>

br>mxmxmx

br>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. br> br>

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.

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. br> br>

br>mxmxmx

br>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. br> br>

br>flts

br>^- 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. br> br>

br>mxmxmx

br>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. br> br>

br>flts

br>

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? br> br>

br>Altitude909

br>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.. br> br>

br>mxmxmx

br>

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? br> br>

br>flts

br>^- 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 br> br>

br>Yeah, 1.6.6 seems to have changed a bunch of settings/warnings. I'll give it a look... br> br>

br>flts

br>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! br> br>

br>pld

br>I can compile it on 1.6.6 with this fix but didn't try it with 1.6.5 or on hardware 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. br> br>

br>mxmxmx

br>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:

br> br>

br>flts

br>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. br> br>

br>pld

br>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

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

br>flts

br>

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

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

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. br> br>

br>sammy123

br>Max I'd like to grab a board.

Have you thought about a random clock mode? br> br>

br>mxmxmx

br>

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 ... ) br> br>

br>flts

br>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 br> br>

br>mxmxmx

br>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? br> br>

br>flts

br>

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. br> br>

br>mxmxmx

br>oh, wait. i think i've inserted a little bug when updating the code the other week:

... 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 ... )

br> br>

br>flts

br>

mxmxmx wrote:

oh, wait. i think i've inserted a little bug when updating the code the other week:

br>... 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. br> br>

br>flts

br>

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. br> br>

br>Altitude909

br>wow. Dont edit panels early in the AM will fix

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

br>flts

br>

Altitude909 wrote:

wow. Dont edit panels early in the AM 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. br> br>

br>mxmxmx

br>

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. br> br>

br>flts

br>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? br> br>

br>mxmxmx

br>

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. br> br>

br>djamsia

br>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

br> br>

br>mxmxmx

br>

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? br> br>

br>djamsia

br>yes i have uncommented..

//#define _TEMPS_UTILE_REV

will review hardware... br> br>

br>mxmxmx

br>

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: br> br>

br>djamsia

br>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.

br> br>

br>mxmxmx

br>

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) br> br>

br>mr.sibs

br>Another working clocks here, thanks mxmxmx for the support and the great modules br> br>

br>flts

br>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. br> br>

br>edwinm

br>If anyone has a spare board please let me know! br> br>

br>puzo

br>Hi. Does this suffer from the 1.3 oled shortage and do we anticipate the 1.4" adapted board from the OC to work? br> br>

br>Altitude909

br>

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) br> br>

br>mxmxmx

br>

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. br> br>

br>puzo

br>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. br> br>

br>Altitude909

br>grr.

didnt catch the wrong pinout on the others.

Anyone have a spare display they want to get rid of in the US? br> br>

br>sammy123

br>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. br> br>

br>Altitude909

br>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? br> br>

br>mxmxmx

br>

Altitude909 wrote:

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

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. br> br>

br>sammy123

br>Actually looking closer I think my adafruit display was the 128x32 for the eurotrash. So I don't think I have a spare. br> br>

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)

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

br> br>

br>Altitude909

br>Hows this look:

br> br>

br>Altitude909

br>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 br> br>

br>mxmxmx

br>

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. br> br>

br>mxmxmx

br>

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 ... br> br>

br>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? br> br>

br>mxmxmx

br>

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. br> br>

br>keninverse

br>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? br> br>

br>mxmxmx

br>

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. br> br>

br>flts

br>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? br> br>

br>flts

br>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. br> br>

br>mxmxmx

br>

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 br> br>

br>flts

br>

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. br> br>

br>mxmxmx

br>

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 ... ) br> br>

br>flts

br>^- 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. br> br>

br>bennelong.bicyclist

br>

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. br> br>

br>mxmxmx

br>

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) br> br>

br>flts

br>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 br> br>

br>Altitude909

br>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?) br> br>

br>flts

br>^- 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... br> br>

br>Altitude909

br>Ah, the dreaded blue PCB. I share your pain br> br>

br>mxmxmx

br>

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. br> br>

br>mxmxmx

br>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)

* 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! br> br>

br>mxmxmx

br>

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 ... br> br>

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 br> br>

br>heapish

br>

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? br> br>

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. br> br>

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. br> br>

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... br> br>

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? br> br>

br>sanderr2

br>

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. br> br>

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
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.

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.

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. br> br>

br>mxmxmx

br>

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 br> br>

br>sanderr2

br>

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.

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! br> br>

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! br> br>

br>mxmxmx

br>

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 br> br>

br>sanderr2

br>Thanks max - a hex file for the old firmware would be great for other relative noobs like me. Cheers, Rob br> br>

br>mxmxmx

br>

sanderr2 wrote:

Thanks max - a hex file for the old firmware would be great for other relative noobs like me. Cheers, Rob

br>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. br> br>

br>mxmxmx

br>

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. br> br>

br>keninverse

br>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? br> br>

br>mxmxmx

br>

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) br> br>

br>keninverse

br>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. br> br>

br>mxmxmx

br>

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! br> br>

br>thelizard

br>Is there an estimate on when the revised firmware will be released? Is there any way that I can help out? br> br>

br>Timmy

br>

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! br> br>

br>mxmxmx

br>

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 ... br> br>

br>heapish

br>

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 br> br>

What's the difference? Has that one more compatibility for future plans? How much posted to the UK? br> br>

br>Sinamsis

br>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! br> br>

br>Sinamsis

br>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! br> br>

br>adnauseam

br>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

br> br>

br>Sinamsis

br>

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

That would confuse the separation of inputs and outputs (different between the two modules) I believe. br> br>

br>mxmxmx

br>

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). br> br>

br>heapish

br>

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 br> br>

br>mxmxmx

br>

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. br> br>

br>keninverse

br>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. br> br>

br>mxmxmx

br>

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. br> br>

br>heapish

br>

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) br> br>

br>mxmxmx

br>

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 br> br>

br>heapish

br>Thankyou for your time br> br>

br>keninverse

br>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. br> br>

br>mxmxmx

br>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. (?) br> br>

br>keninverse

br>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! br> br>

br>heapish

br>In the bom the through hole caps have RM written after them, is that lead spacing? br> br>

br>mxmxmx

br>

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. br> br>

br>mxmxmx

br>

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. br> br>

br>heapish

br>

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 Thankyou br> br>

br>toneburst

br>@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

Cheers,

a|x br> br>

br>mxmxmx

br>

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... br> br>

br>toneburst

br>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 br> br>

br>mxmxmx

br>

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. br> br>

br>toneburst

br>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 br> br>

br>audiohawk

br>PCBs arrived safe. Thank you for your work br> br>

br>mxmxmx

br>

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. br> br>

br>toneburst

br>Sounds good!
Looking forward to assembling mine.

a|x br> br>

br>mxmxmx

br>

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.

- 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. br> br>

br>keninverse

br>Sweet. I'll get this flashed soon. CV over sequencing would be very useful. Is the internal clock still in the works? br> br>

br>Timmy

br>

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. br> br>

br>mxmxmx

br>

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) br> br>

br>Timmy

br>

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! br> br>

br>Sinamsis

br>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. br> br>

br>keninverse

br>

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. br> br>

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:

br>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. br> br>

br>Sinamsis

br>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? ), 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? br> br>

br>nevetsokyeron

br>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.

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. br> br>

br>mxmxmx

br>

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 br> br>

br>m0d

br>

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. br> br>

br>mxmxmx

br>

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.

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. br> br>

br>Sinamsis

br>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. br> br>

br>nevetsokyeron

br>

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. br> br>

br>mxmxmx

br>

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. br> br>

br>Sinamsis

br>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. br> br>

br>thelizard

br>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. br> br>

br>mxmxmx

br>

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. br> br>

br>pld

br>

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. br> br>

br>thelizard

br>

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. br> br>

br>mxmxmx

br>

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. br> br>

br>thelizard

br>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?

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.

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? br> br>

br>mxmxmx

br>

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.

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. br> br>

br>justin3am

br>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? br> br>

br>thelizard

br>

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.

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. br> br>

br>justin3am

br>

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? br> br>

br>mxmxmx

br>

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. br> br>

br>justin3am

br>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. br> br>

br>thelizard

br>

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.

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. br> br>

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. br> br>

br>thelizard

br>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! br> br>

br>justin3am

br>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! br> br>

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] br> br>

br>thelizard

br>

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.

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. br> br>

br>mxmxmx

br>

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.

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.

I'll do some research later and see if I can order a batch of TU PCBs. br> br>

br>Timmy

br>

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.

-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. br> br>

br>Timmy

br>

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. br> br>

br>Timmy

br>

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? br> br>

br>mxmxmx

br>

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) br> br>

br>sockmonkey

br>

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)"? br> br>

br>diablojoy

br>Sex urn sounds good to me br> br>

br>Timmy

br>

diablojoy wrote:

Sex urn sounds good to me

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? br> br>

br>Timmy

br>

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")

yes, should be ok. fwiw, the BOM including parts # is here; it comes with the one Tim mentioned. br> br>

br>toneburst

br>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 br> br>

br>thelizard

br>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 br> br>

br>mxmxmx

br>

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' br> br>

br>dusk

br>ordering parts now, can't wait to dive into it! br> br>

br>Sinamsis

br>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. br> br>

br>mxmxmx

br>

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. br> br>

br>Sinamsis

br>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! br> br>

br>Timmy

br>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. br> br>

br>mxmxmx

br>

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. br> br>

br>dusk

br>

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.

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? br> br>

br>mxmxmx

br>

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?

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. br> br>

br>mxmxmx

br>

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. br> br>

br>dusk

br>

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. br> br>

br>dusk

br>

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.

br>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. br> br>

br>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! br> br>

br>mxmxmx

br>

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 br> br>

br>nevetsokyeron

br>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! br> br>

br>nevetsokyeron

br>

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?

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. br> br>

br>mxmxmx

br>

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?

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. br> br>

br>nevetsokyeron

br>

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

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. br> br>

br>mxmxmx

br>

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. br> br>

br>jcarruthers

br>Anyone got any ideas where to get a PCB for this? br> br>

br>toneburst

br>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 br> br>

br>nevetsokyeron

br>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! br> br>

br>mxmxmx

br>

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?) ?

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? br> br>

br>mxmxmx

br>

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?

br>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? br> br>

br>mxmxmx

br>

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. br> br>

br>nevetsokyeron

br>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"? br> br>

br>mxmxmx

br>

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 br> br>

br>nevetsokyeron

br>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? br> br>

br>nevetsokyeron

br>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. br> br>

br>mxmxmx

br>

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) br> br>

br>nevetsokyeron

br>

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. br> br>

br>mxmxmx

br>

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. br> br>

br>nevetsokyeron

br>

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. br> br>

br>nevetsokyeron

br>Some basic wiggling tonight...

(internal clocks MULT/DIV with one SEQ)

br> br>

br>mxmxmx

br>

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. br> br>

br>nevetsokyeron

br>

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. br> br>

br>mxmxmx

br>

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 br> br>

br>nevetsokyeron

br>

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. br> br>

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. br> br>

br>n0rd

br>@mxmxmx, PM'ed you regarding PCBs. Cheers. br> br>

br>mxmxmx

br>

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. br> br>

br>gerald

br>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 br> br>

br>mxmxmx

br>

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.

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.

br> br>

br>nevetsokyeron

br>

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. br> br>

br>nevetsokyeron

br>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. br> br>

br>mxmxmx

br>

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. br> br>

br>nevetsokyeron

br>

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! br> br>

br>gerald

br>

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. br> br>

br>nevetsokyeron

br>

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.

br> br>

br>sockmonkey

br>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... br> br>

br>mxmxmx

br>

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. br> br>

br>sockmonkey

br>

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. br> br>

br>Jaypee

br>

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.

br>followed the instructions on the firmware page. all seems well now! thanks for the help~! br> br>

br>mxmxmx

br>

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. br> br>

br>masterofstuff124

br>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. br> br>

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. br> br>

br>mxmxmx

br>

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).

br>excellent.. i soldered a jumper wire across to the resistor next to it, fingers crossed it'll work br> br>

br>shiftr

br>

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. br> br>

br>dusk

br>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? br> br>

br>lasesentaysiete

br>

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. br> br>

br>dusk

br>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? br> br>

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

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

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? br> br>

br>dusk

br>

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

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 br> br>

br>nevetsokyeron

br>

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 (?).

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. br> br>

br>dusk

br>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. br> br>

br>nevetsokyeron

br>

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. br> br>

br>dusk

br>

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... br> br>

br>nevetsokyeron

br>

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. br> br>

br>dusk

br>tried both teensys with the same outcome :( br> br>

br>nevetsokyeron

br>Looking at the PCB files I see the 78L33 is supplying 3.3v to the display.

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.

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. br> br>

br>dusk

br>

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.

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.

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. br> br>

br>mxmxmx

br>

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. br> br>

br>dusk

br>

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.

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?

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! br> br>

br>nevetsokyeron

br>

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 br> br>

br>strange tales

br>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.

br>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? br> br>

br>mxmxmx

br>

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.

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).) br> br>

br>Sinamsis

br>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! br> br>

br>sockmonkey

br>

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. br> br>

br>Sinamsis

br>sockmonkey
You da bomb, thanks so much. br> br>

br>mxmxmx

br>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. br> br>

br>Sinamsis

br>

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. br> br>

br>Sinamsis

br>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. br> br>

br>mxmxmx

br>

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. br> br>

br>Sinamsis

br>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. br> br>

br>mxmxmx

br>

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. br> br>

br>Sinamsis

br>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! br> br>

br>Sinamsis

br>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. br> br>

br>nevetsokyeron

br>

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. br> br>

br>heapish

br>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 br> br>

br>mxmxmx

br>

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. br> br>

br>mxmxmx

br>

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...) br> br>

br>heapish

br>Thank you. Sorry its not 3. I mean the connector bit. I've taken a picture. Next to the 0.33uf. br> br>

br>mxmxmx

br>

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.

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.

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. br> br>

br>strange tales

br>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. br> br>

br>mxmxmx

br>

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. br> br>

br>diablojoy

br>Hi mxmxmx
just wondering if you had any boards available still ? br> br>

br>mxmxmx

br>

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. br> br>

br>diablojoy

br>Awesome
thanks! br> br>

br>Altitude909

br>If anyone in the US is looking for boards, I have more than I need. $10 shipped, drop me a PM br> br>

br>heapish

br>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 br> br>

br>m0d

br>"Comment out" essentially means adding // to the beginning of a line. The line in your screenshot is already commented out. br> br>

br>mxmxmx

br>

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 '//'. br> br>

br>heapish

br>Right cool. Remove the //
Rolling. br> br>

br>webboy

br>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. br> br>

br>webboy

br>Well that was easy - it was the flux. I'll just leave this here as a cautionary tale. 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.

br> br>

br>webboy

br>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. br> br>

br>toneburst

br>

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 br> br>

br>mxmxmx

br>

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. br> br>

br>webboy

br>Thanks for the answers gents. br> br>

br>Sammus

br>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? br> br>

br>mxmxmx

br>

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 br> br>

br>blip

br>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 ? br> br>

br>mxmxmx

br>

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). br> br>

br>blip

br>Thanks for your quick answer Max.
I have plenty of 100n so i will use them instead. br> br>

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. br> br>

br>nevetsokyeron

br>

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.

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. br> br>

br>heapish

br>

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. br> br>

br>heapish

br>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 br> br>

br>mxmxmx

br>

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 br> br>

br>Sammus

br>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? br> br>

br>mxmxmx

br>

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. br> br>

br>heapish

br>

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) br> br>

br>heapish

br>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. br> br>

br>diablojoy

br>still looking for a board
mxmxmx any available ? br> br>

br>mxmxmx

br>

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?

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. br> br>

br>diablojoy

br>PM sent
thanks br> br>

br>Sammus

br>

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. br> br>

br>heapish

br>I've pm'd you about a fresh pcb br> br>

br>mxmxmx

br>

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. br> br>

br>flts

br>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. br> br>

br>Sammus

br>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. br> br>

br>mxmxmx

br>

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. br> br>

br>Sammus

br>

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. br> br>

br>mxmxmx

br>

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. br> br>

br>Sammus

br>

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 br> br>

br>mxmxmx

br>

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. br> br>

br>Sammus

br>

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? br> br>

br>mxmxmx

br>

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. br> br>

br>Sammus

br>

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. br> br>

br>pld

br>

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? br> br>

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 :( br> br>

br>Sammus

br>

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. br> br>

br>Sammus

br>Oops - double post. br> br>

br>mxmxmx

br>

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. br> br>

br>bemerritt

br>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 br> br>

br>mxmxmx

br>

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. br> br>

br>bemerritt

br>

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. br> br>

br>nevetsokyeron

br>

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? br> br>

br>mxmxmx

br>

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. br> br>

br>nevetsokyeron

br>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? br> br>

br>mxmxmx

br>

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? br> br>

br>nevetsokyeron

br>

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. br> br>

br>mxmxmx

br>

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? br> br>

br>nevetsokyeron

br>

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. br> br>

br>nevetsokyeron

br>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) br> br>

br>mxmxmx

br>

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 br> br>

br>Dark Barn

br>Can TU be slaved to an external clock running at 24 PPQN? br> br>

br>gimber

br>

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. br> br>

br>mxmxmx

br>

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:

br>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 br> br>

br>mxmxmx

br>

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. br> br>

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. br> br>

br>Macc29

br>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.

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. br> br>

br>Macc29

br>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. br> br>

br>Macc29

br>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. br> br>

br>mxmxmx

br>

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.

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. br> br>

br>Macc29

br>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 br> br>

br>mxmxmx

br>

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! br> br>

br>wavefold

br>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) br> br>

br>Macc29

br>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 br> br>

br>mxmxmx

br>

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):

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) br> br>

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 br> br>

br>xbted

br>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 br> br>

br>mxmxmx

br>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. br> br>

br>xbted

br>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!!!! br> br>

br>xbted

br>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.

br> br>

br>Virgil

br>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). br> br>

br>mxmxmx

br>

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. br> br>

br>Virgil

br>That's much better, thanks br> br>

br>wavefold

br>

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! br> br>

br>boerker

br>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

br> br>

br>mxmxmx

br>

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). br> br>

br>mxmxmx

br>

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.

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...) br> br>

br>Dark Barn

br>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! br> br>

br>n0rd

br>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.

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. br> br>

br>n0rd

br>

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) br> br>

br>bemerritt

br>

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! br> br>

br>mxmxmx

br>

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. br> br>

br>bemerritt

br>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. br> br>

br>mxmxmx

br>

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. br> br>

br>Timmy

br>

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.

br> br>

br>sempervirent

br>Thanks for the feedback, I've updated the CLK/RST to TR1/TR2 graphics. br> br>

br>bemerritt

br>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.

br>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" br> br>

br>mxmxmx

br>

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? br> br>

br>Dark Barn

br>Either with run/stop or reset pulses. br> br>

br>bemerritt

br>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. br> br>

br>mxmxmx

br>

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. br> br>

br>mxmxmx

br>

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? br> br>

br>bemerritt

br>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? br> br>

br>abozzelli

br>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 br> br>

br>mxmxmx

br>

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. br> br>

br>abozzelli

br>

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.

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 br> br>

br>mxmxmx

br>

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. br> br>

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. br> br>

br>n0rd

br>

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 br> br>

br>mxmxmx

br>

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? br> br>

br>n0rd

br>

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 br> br>

br>mxmxmx

br>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. br> br>

br>n0rd

br>

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. br> br>

br>mxmxmx

br>

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....

br> br>

br>LSuveg1

br>[text moved to next post w/photo] br> br>

br>LSuveg1

br>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: br> br>

br>mxmxmx

br>

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. br> br>

br>LSuveg1

br>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! br> br>

br>mxmxmx

br>

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. br> br>

br>gimber

br>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. br> br>

br>mxmxmx

br>

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. br> br>

br>gimber

br>

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. br> br>

br>mxmxmx

br>

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. br> br>

br>pirxthepilot

br>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! br> br>

br>mxmxmx

br>

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. br> br>

br>Sven

br>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? br> br>

br>mxmxmx

br>

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. br> br>

br>sammy123

br>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.

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. br> br>

br>mxmxmx

br>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. br> br>

br>sammy123

br>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.

br> br>

br>Dunk_91

br>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! br> br>

br>mxmxmx

br>

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? br> br>

br>Dunk_91

br>

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!

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 br> br>

br>whyfarer

br>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! br> br>

br>mxmxmx

br>

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. br> br>

br>whyfarer

br>

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 br> br>

br>trimix

br>

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! br> br>

br>mxmxmx

br>

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. br> br>

br>trimix

br>[/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? br> br>

br>mcop

br>Here's two I've just finished. Having a lot of fun with them.
Thanks to all involved developing this.

br> br>

br>mxmxmx

br>

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 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! br> br>

br>mxmxmx

br>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). br> br>

br>nso_music

br>any builders selling built TU's? (apologies if this is not the right place to ask ) br> br>

br>Altitude909

br>Would help if you stated where you're located br> br>

br>nso_music

br>

Altitude909 wrote:

Would help if you stated where you're located

sure would! US, new england area br> br>

br>sduck

br>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... br> br>

br>PulletSurprise

br>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? br> br>

br>sduck

br>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? br> br>

br>mxmxmx

br>

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. br> br>

br>taichber

br>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 ) br> br>

br>nevetsokyeron

br>

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.

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). br> br>

br>toneburst

br>+1 for a shuffle feature here, too.

a|x br> br>

br>taichber

br>

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. br> br>

br>ebardie

br>I've just built and am using my TU, and everything I've tested/tried so far is working

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 - 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? br> br>

br>keninverse

br>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. br> br>

br>mxmxmx

br>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. br> br>

br>ebardie

br>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

Now on the TT build... br> br>

br>mxmxmx

br>

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 br> br>

br>pld

br>

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.

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... br> br>

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) br> br>

br>lohacker

br>Hello Max,
could be possible to add internal attenuators for the CV inputs in the CV assign page?

Thanks, loving TU br> br>

br>mxmxmx

br>

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 (?). br> br>

br>lohacker

br>

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! br> br>

br>DeWalta

br>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? br> br>

br>mxmxmx

br>

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 br> br>

br>wavedepletion

br>Finished build:

br> br>

br>artistcalled6

br>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.

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)

chances are this introduced some bugs ... let me know, if you can find any. br> br>

br>taichber

br>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! br> br>

br>taichber

br>

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... br> br>

br>taichber

br>double post br> br>

br>mxmxmx

br>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

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

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? br> br>

br>mxmxmx

br>

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). br> br>

br>taichber

br>

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. br> br>

br>taichber

br>

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
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 :-) br> br>

br>mxmxmx

br>

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. br> br>

br>SlyFrank

br>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. br> br>

br>mxmxmx

br>

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 br> br>

br>SlyFrank

br>

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?

br>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) br> br>

br>Sammus

br>Like a trigger repeat or ratcheting effect? Could be pretty sweet. br> br>

br>basicbasic

br>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. br> br>

br>flab

br>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 ? br> br>

br>mxmxmx

br>

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. br> br>

br>flab

br>Ok , thanks boss, I will get one from you then a bit later, thanks for your answer br> br>

br>SlyFrank

br>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 br> br>

br>basicbasic

br>Solder the metal tabs to the PCB. Not sure whats in the pic but most likely a different package or something. br> br>

br>SlyFrank

br>

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 br> br>

br>basicbasic

br>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. br> br>

br>mxmxmx

br>

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). br> br>

br>SlyFrank

br>

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 br> br>

br>basicbasic

br>

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 br> br>

br>SlyFrank

br>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. br> br>

br>keninverse

br>

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? br> br>

br>sempervirent

br>

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. br> br>

br>mxmxmx

br>

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? br> br>

br>Dark Barn

br>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? br> br>

br>mxmxmx

br>

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.

br>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. br> br>

br>lohacker

br>

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.

- 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 br> br>

br>Funkydroid

br>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? br> br>

br>Sammus

br>

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?

Yes br> br>

br>Psy'low

br>Would it be possible to add extra divider in the MULT such as 128 , 256, 512? br> br>

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. br> br>

br>aragorn23

br>Ah, thanks pld :-) br> br>

br>lohacker

br>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! br> br>

br>pld

br>

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!

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.) br> br>

br>paulg

br>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? br> br>

br>pld

br>

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... br> br>

br>paulg

br>pld gotcha. For what it's worth I think that'd be a very worthwhile addition br> br>

br>Rowan

br>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 br> br>

br>Altitude909

br>

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 br> br>

br>patchack

br>Hi all,
Any idea for a replacement of those 470nF capacitors (77-VJ0805Y474JXJTBC)? There's no stock on mouser. Does tolerance really matters ?
Thanks ! br> br>

br>patchack

br>I found this one ref mouser 80-C0805C474J3R . I mingled nano and pico Now i have to check all my cart... br> br>

br>adh82

br>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? br> br>

br>pld

br>

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 For o_C at least the better nomenclature would have been along the lines of "visualization" but flying toasters, old habits, etc. br> br>

br>adh82

br>[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 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:

Just a few quick ideas.
Maybe bits of the quantimain could be used? br> br>

br>pld

br>Yep. The trick is designing simple ways of (usefully) representing the information within the constraints. But as they say, simple is not easy At say 42x64px per channel and the font being 6x8, eventually every pixel starts to count and even 1px spacings can add up... br> br>

br>adh82

br>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. br> br>

br>Llewspeed

br>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? br> br>

"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)" br> br>

"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! br> br>

br>aragorn23

br>

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... br> br>

br>abozzelli

br>

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 br> br>

br>adh82

br>Just wondering if there is anyway to delay triggers per channel?
Would love to add a little groove to some patterns br> br>

br>pld

br>

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... br> br>

br>adh82

br>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? br> br>

br>pld

br>

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?

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. br> br>

br>adh82

br>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. br> br>

br>nimmen

br>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? br> br>

br>nimmen

br>False alarm, after some tries with older firmware seems to be working now. br> br>

br>lohacker

br>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.

br> br>

br>lohacker

br>Self bump, anyone checked this?

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.

br> br>

br>n0rd

br>

lohacker wrote:

anyone checked this?

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 br> br>

br>pld

br>

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. br> br>

br>lohacker

br>

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. br> br>

br>n0rd

br>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 br> br>

br>pld

br>

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

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. br> br>

br>mxmxmx

br>[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.

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).

br>Nice! did you build this yourself? or does someone sell this premade?

Caseyjholmes wrote:

Thank you! Great module!!!

br> br>

br>Caseyjholmes

br>Thanks! I built this one.
Really great module. It's running my whole system right now. br> br>

br>Ray Diode

br>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... br> br>

br>mxmxmx

br>

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:

br>Fab!
Will invest in a soldering iron and sort it.
Thanks for the reply and kick-ass module. br> br>

br>basicbasic

br>

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. br> br>

br>autodafe

br>Just build mine.
worked 90% at first try
I get nothing out of Outs 1 and 4...should I check the TL074s ??? br> br>

br>mxmxmx

br>

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 br> br>

br>autodafe

br>thx for your reply.I already reflowed both TL074 more than once, I need to check resistors and capacitors. i'll let you know br> br>

br>autodafe

br>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 br> br>

br>Altitude909

br>

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 br> br>

br>Handmedown

br>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 br> br>

br>Handmedown

br>

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 br> br>

br>autodafe

br>

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 br> br>

br>Mirland

br>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? br> br>

br>flts

br>

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 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... br> br>

br>Mirland

br>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 br> br>

br>0netwo0netwo

br>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 br> br>

br>DabiDabDab

br>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 br> br>

br>DabiDabDab

br>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! br> br>

br>DabiDabDab

br>I guess hole under the dac pin and the pin should be connected? Meh br> br>

br>mattsb

br>

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.

br>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?? br> br>

br>flts

br>

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. br> br>

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). br> br>

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).

br>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? br> br>

br>keninverse

br>Wait...works fine over USB? Did you cut the jumper on Vin and Vusb? br> br>

br>tdball

br>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. br> br>

br>mush

br>

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 br> br>

br>Altitude909

br>

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 br> br>

br>tdball

br>

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. br> br>

br>tdball

br>

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? br> br>

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 br> br>

br>tdball

br>

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 br> br>

br>Altitude909

br>^
Old rev. br> br>

br>tdball

br>

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? br> br>

br>Altitude909

br>

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. br> br>

br>tdball

br>

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! br> br>

br>wardour

br>deleted br> br>

br>wavedepletion

br>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. br> br>

br>Sammus

br>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. br> br>

br>gimber

br>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 br> br>

br>mxmxmx

br>

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

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 br> br>

br>soundslikejoe

br>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? br> br>

br>mxmxmx

br>

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) br> br>

br>soundslikejoe

br>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? br> br>

br>mxmxmx

br>

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. br> br>

br>DJ_JITTER

br>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? br> br>

br>mxmxmx

br>

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? br> br>

br>DJ_JITTER

br>

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. br> br>

br>Supervillain

br>Hey,
I don't really get how RST1 and RST2 work...
What's the difference with low/hi setting? br> br>

br>mxmxmx

br>

Supervillain wrote:

Hey,
I don't really get how RST1 and RST2 work...
What's the difference with low/hi setting?

br>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! br> br>

br>mxmxmx

br>

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 br> br>

br>pld

br>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.

P.S. if anyone has a spare ut_U or 1U PCB/panel... hint hint. br> br>

br>lohacker

br>Great news! I was waiting for saving slots for a long time, can't wait to try it asap br> br>

br>timmmofa

br>this is amazing! br> br>

br>Bamboombaps

br>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... br> br>

br>mxmxmx

br>

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.)

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. br> br>

br>Bamboombaps

br>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? br> br>

br>mxmxmx

br>

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) br> br>

br>mxmxmx

br>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:

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. br> br>

br>keninverse

br>Brilliant. Thank you! br> br>

br>lohacker

br>Wow, the burst mode now is a gem and the save/load slots are a great addition! Thanks br> br>

br>mxmxmx

br>

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).

br>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. br> br>

br>mxmxmx

br>

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 br> br>

br>FrJK

br>

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? br> br>

br>mxmxmx

br>

FrJK wrote:

Great, thanks. Will you provide an updated hex file in the next few days?

br>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! br> br>

br>mxmxmx

br>

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. br> br>

br>midirobot

br>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 ^^ br> br>

br>mutronic

br>

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. br> br>

br>DJ_JITTER

br>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? br> br>

br>mxmxmx

br>

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 br> br>

br>DJ_JITTER

br>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:

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! br> br>

br>mxmxmx

br>

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? br> br>

br>terje_t

br>

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. br> br>

br>mxmxmx

br>

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 br> br>

br>terje_t

br>Thanks for the tip! I’ll consider it br> br>

br>Sammus

br>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. br> br>

br>mutronic

br>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. br> br>

br>mutronic

br>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.

br>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. br> br>

br>terje_t

br>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.

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? br> br>

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. br> br>

br>ricwadsworth

br>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? br> br>

br>terje_t

br>

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? br> br>

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 ... br> br>

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.

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. br> br>

br>djthopa

br>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

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 br> br>

br>ricwadsworth

br>

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

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.

br> br>

br>djthopa

br>

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

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! br> br>

br>ricwadsworth

br>

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 br> br>

br>matjinks

br>Hi There, I just finished a Temps build and everything except out 4 is working, any ideas? also what is the DAC jumper for and which legs should be jumped to do what exactly? I cannot find any info on the DAC jumper in build info or in use must be an oversight?

Thanks for help,

Mathew. br> br>

br>Altitude909

br>

matjinks wrote:

Hi There, I just finished a Temps build and everything except out 4 is working, any ideas? also what is the DAC jumper for and which legs should be jumped to do what exactly? I cannot find any info on the DAC jumper in build info or in use must be an oversight?

Thanks for help,

Mathew.

> also what is the DAC jumper for

To make output 4 work

Out 4 is actually coming from the DAC as a clock signal. It's a bit of a legacy thing but the originally idea was to have that available as a CV output for some apps and the jumper was to switch between a clock out only and the DAC channel on the teensy. It never was really implemented on any apps AFAIK and the current config simply has the DAC spit out a square wave. CLK4 is a pad on the underside of the teensy that no one ever uses since its such a PITA to connect. Its routed on uTemps and you can use a pogo pin just like for the supervisor to enable it hardware wise but IDK what is required software wise to use it. The DAC clock out only goes to 4V instead of 5 too..

I would just use a wire lead and jump the DAC postion of the holes for the header br> br>

br>matjinks

br>

Altitude909 wrote:

matjinks wrote:

Hi There, I just finished a Temps build and everything except out 4 is working, any ideas? also what is the DAC jumper for and which legs should be jumped to do what exactly? I cannot find any info on the DAC jumper in build info or in use must be an oversight?

Thanks for help,

Mathew.

> also what is the DAC jumper for

To make output 4 work

Out 4 is actually coming from the DAC as a clock signal. It's a bit of a legacy thing but the originally idea was to have that available as a CV output for some apps and the jumper was to switch between a clock out only and the DAC channel on the teensy. It never was really implemented on any apps AFAIK and the current config simply has the DAC spit out a square wave. CLK4 is a pad on the underside of the teensy that no one ever uses since its such a PITA to connect. Its routed on uTemps and you can use a pogo pin just like for the supervisor to enable it hardware wise but IDK what is required software wise to use it. The DAC clock out only goes to 4V instead of 5 too..

I would just use a wire lead and jump the DAC postion of the holes for the header

Ahhh I see so am I right in thinking output 4 is really only a DAC so in the firmware I should only choose the DAC option, unless I have a pogo installed to activate CLK4? And also I should have the pins jumped for DAC activation to make the DAC turn on. I’ll try this later tonight, thanks for the input I love this little module as an underdog to PNW br> br>

br>Altitude909

br>^
Yep, you got it. u dont have to change anything for the DAC out to be on, that's the default state. The CLK4 out very well may be as well so you only have to switch the jumper br> br>

br>matjinks

br>

Altitude909 wrote:

^
Yep, you got it. u dont have to change anything for the DAC out to be on, that's the default state. The CLK4 out very well may be as well so you only have to switch the jumper

Strangely enough I am still not getting anything from no 4 out even with the DAC enabled, everything else works on the module, I tried reflowing some IC’s and smt’s But nothing changed br> br>

br>matjinks

br>

matjinks wrote:

Altitude909 wrote:

^
Yep, you got it. u dont have to change anything for the DAC out to be on, that's the default state. The CLK4 out very well may be as well so you only have to switch the jumper

Strangely enough I am still not getting anything from no 4 out even with the DAC enabled, everything else works on the module, I tried reflowing some IC’s and smt’s But nothing changed

Okay my bad I did not have the extra pin on the header to connect to CLK4 on the Teensy now all works great, just need to calibrate now br> br>

br>shiny saw

br>Hi you all,

I've just finished building micro T_u. At certain point shortly after switching it on, the oled screen offsets its X position a bit, and then weird things happens. I could load the firmware, and calibrated it. Finally it went black and stayed like that in the next bootups. While screen off, the module was working (it was sending pulses to the clock received at TR1).

After a while I tried again and the screen was back, but the process of 'corruption' started again. You can see this in pictures attached.

After the last start up, it didn't go into weird display. It stayed normal for some minutes, and then R60 burned. I don't know whether this is related to the screen problem or not.

Any idea? My electronics knowledge is very basic. Thanks for helping.. br> br>

br>mxmxmx

br>

shiny saw wrote:

Hi you all,

I've just finished building micro T_u. At certain point shortly after switching it on, the oled screen offsets its X position a bit, and then weird things happens. I could load the firmware, and calibrated it. Finally it went black and stayed like that in the next bootups. While screen off, the module was working (it was sending pulses to the clock received at TR1).

After a while I tried again and the screen was back, but the process of 'corruption' started again. You can see this in pictures attached.

After the last start up, it didn't go into weird display. It stayed normal for some minutes, and then R60 burned. I don't know whether this is related to the screen problem or not.

Any idea? My electronics knowledge is very basic. Thanks for helping..

not really, but if R60 went up in flames chances are the OLED corruption is a symptom of something else. i'd start with removing the OLED and teensy and check for shorts; also make sure the LM1117 actually outputs 5V. br> br>

br>shiny saw

br>

mxmxmx wrote:

not really, but if R60 went up in flames chances are the OLED corruption is a symptom of something else. i'd start with removing the OLED and teensy and check for shorts; also make sure the LM1117 actually outputs 5V.

thanks for the heads-up! I'm waiting for arrival of R60 replacements and a 10x loupe to do that. :-) br> br>

br>shiny saw

br>

mxmxmx wrote:

not really, but if R60 went up in flames chances are the OLED corruption is a symptom of something else. i'd start with removing the OLED and teensy and check for shorts; also make sure the LM1117 actually outputs 5V.

Well, I removed the OLED and Teensy. I've minutely looked for shorts but I couldn't find any. R60 keeps burning, I had to solder a new one to check the LM1117 is indeed outputting 5v. (at least, before R60 went up in flames again). I don't know what else can I do.. br> br>

br>patchack

br>Hi there,
It seems Reset does not work on my T_U whatever i send in a pulse trigger or a gate. It's stange because Mute works fine. So, i doesn't think it's a hardware issue, but i dunno...
The firmware is v1.3.1b.

Any idea?

Thanks for help ! br> br>

br>mxmxmx

br>

patchack wrote:

Hi there,
It seems Reset does not work on my T_U whatever i send in a pulse trigger or a gate. It's stange because Mute works fine. So, i doesn't think it's a hardware issue, but i dunno...
The firmware is v1.3.1b.

Any idea?

Thanks for help !

which mode(s)? reset only works (should work) for division, the pattern sequencer, and the euclidian stuff. br> br>

br>patchack

br>

mxmxmx wrote:

which mode(s)? reset only works (should work) for division, the pattern sequencer, and the euclidian stuff.

Thanks for your help.
I tested in sequencer and euclidean modes and yes, it does not work in these modes. br> br>

br>patchack

br> it looks i needed to sleep a bit... Now reset works like a charm. Really sorry.
Temps Utile is the perfect tool for clock works !
Thanks again. br> br>