Taking @eric 's advice I did one heck of a kludge, using a spare TL071 to buffer the VREF as it comes out of the trim pot and before it goes to the rest of the circuit. I’m still getting 4.07 on the LM4040AIZ but the VREF (and thus the tuning) has stayed consistent for three power cycles, which is a first. Too soon to call this a win but I’m letting my self dare to hope this issue might be solved. Sadly it totally invalidates the stripboard layout I had planned to share. I guess potentially serving as a reference for 12 DAC channels at once was too much for the little guy. In any case, thanks a million to you both, Analogoutput and Eric, for the solid advice and talking me through a brief bout of hobby electronics hysteria.
3 Likes
Have you measured the pot resistance from top to wiper? If the DACs were presenting a VERY low impedance then to get your 2.07 V you might have to sit close to the top of the pot giving a load of much lower than the ~50k you’d assume. Then that would increase the current the LM4040 has to supply. Still, to bring it up above the 15 mV it’s specced to handle you’d need R = 4.1/.015 = 270R or 0.3% of the pot, which is hard to believe. Also hard to believe the DACs would put that kind of load on their voltage reference. It still makes no sense.
Added: Input impedance for unbuffered V_Ref is supposed to be 165k.
1 Like
Well, the TL071 VREF buffer seems unneeded from a theory perspective, but it seems to have solved the problem, so I’m going to ignore it for now since that part of the circuit will be eliminated in the final design anyway.
This thing has been rock solid and super fun to play with for the last 5 days, and now I’m looking into one of the last hardware feature’s I’d like to add - analog slew rate limiters. I might start a new thread on the topic, but does anyone know of a good slew rate limiter circuit that meets the following criteria?
- Relatively simple
- No need for “true bypass” (pot rolled all the way to zero will cause almost no slew rate limiting)
- Has appropriate response curve for oscillator portamento (exponential curve? IDK)
I plan to make two four channel busses with behind-the-panel micro switches that will allow the user to dictate which channels are used for driving oscillators (or keyboard tracking) and should be subjected to slew rate limiting. The tricky thing here is that all four channels will be affected by a single pot, rather than individually. I’m not sure if this can be done with one pot, or if a 4 gang pot will need to be used. All channels don’t need to be perfectly matched, just in the ball park. Here is a block diagram of what I’m talking about:
Since there will be two instances of these 4-slew-rate-limiter-circuits, this means I will be cramming 8 slew rate limiters in - obviously simpler is better in this context, but I would like to go one step beyond a simple resistor and cap, if it will have any noticeable impact on the quality of the circuit.
If anyone knows of any good portamento circuits that I can model my efforts after, feel free to post some links!
Cheers
2 Likes
Slew, Glide, Portamento ? i don’t know really the difference between each
but i made this Glide
i added this on mine
2 Likes
I’m using slew, glide, and portamento interchangeably here, but I suppose glide and portamento are synonyms describing when slew is applied to oscillator pitch. Thanks for showing me this circuit, I will check it out!
1 Like
Ok. I’ll have a bash;
A Slew is note with an initial offset ± to the one note/voltage it resolves to.
A Glide is a slide (usually linear) between two notes.
Portamento is to ‘carry’ one note/sound over to the start of the next. (you can wibble, slide,glide,slew, bend or simply step the next note). Though commonly a synonym for a glide the portamento notation is useful for breathing, bowing, hitting or plucking and in synths? Well mostly used as a linear ‘changer’,
In a synth I think portamento works really well with odd waveforms, for me that’s mostly FM sounds and odd “ringy/bongy*” sounds. On a simpler square wave I think of any portamento as a cute pitch bend but otherwise I avoid it.
Ok, I’ve thrown too many brackets, N3Ts*, and probably meds down this logical rabbit hole. Enjoy!
- N3T = a Not True Technical Term
a.k.a. MUF - Made Up Fact
2 Likes
Hey all I’m back on this project again - I’ve had a working prototype in my rack for years and now I’m re-doing it with a custom PCB and a teensy 4.1 (shoulda gone 4.0 but oh well).
Anyway, I am absolutely losing my mind over the fact that I’m receiving garbled midi messages through 5 pin DIN. USB midi is working fine. I’m wondering if anyone else has encountered this issue on the teensy 4 platform. Here’s what I’ve tried:
- Replacing the teensy to make sure my hardware uart isn’t busted
- Replace the optical isolator 3 times
- pull the midi input circuit off my pcb and rebuild it off board, manually wiring into the teensy from vero board
- ditching the midi library and manually parsing the hardware serial information to see if it’s a midi library issue (it doesn’t appear to be).
- Manually powering/grounding the midi inputs to make sure the RX pin on the arduino goes high and low (it goes from about +3.27 to about 0.05.
A midi input circuit is a pretty simple thing I’m looking at it and I can’t for the life of me find anything wrong. I was out of 220 ohm resistors for the input resistor but I’ve used 200 plenty of times in the past without issue. The midi messages I’m receiving are incorrect, but they are incorrect in a consistent way, rather than being totally random. I’ve been banging my head against this for hours upon hours. Has anyone seen this kind of thing before?
Best,
-Wes
1 Like
Replaced as in “replaced with the same part” (to check whether it was faulty), or with a different part? Probably a shot in the dark, but I read that people had problems because some optocouplers (that are often specified in MIDI circuits) are too slow for MIDI messages.
I’ve been putting off this problem while I grind on the software. Anyway I fully pulled my teensy 4.1 out of the circuit and soldered the midi input circuit directly to it, and isolated it all from the rest of the PCB still having problems!
Not my cleanest soldering, but I confirmed with a multimeter that there are no shorts. I tracked down a 220ohm resistor so all the resistor values and part numbers are precisely in line with this schematic from pjrc:
I am using the PJRC example code given on that webpage as well. I’ve stripped it down to the bare essentials, confirmed all the connections with a continuity meter, I have absolutely no idea what I’m doing wrong here. I still get midi messages, but they are all garbled nonsense. This at least rules out the midi input wires being switched, since that would give no data at all (and I tried it).
I’m sticking with the 6N138 because I know it works in other circuits I use, and it’s recommended on the PJRC website. I also tried using multiple different midi sources to make sure it wasn’t the sending device. No joy. If I had any hair left I’d be tearing it out.
1 Like
If you’re getting a signal, even if it’s garbled, then a likely culprit is a baud mismatch. (The speed of the serial communication)
Are you coding using the pjrc audio system design tool to generate the setup code? I seem to remember there was a midi block available there and that the midi setup is handled differently on v4.0 and above. Have a look at YouTube’s Notes and Volts teensy build too.
Arrrrgh I think I finally figured it out. the PJRC page mentions that for many 6n138s an extra 10k resistor is needed from 7 to GND. They mention it in the article but don’t show it in the diagram. Thank was my issue. Thanks for getting me to look more closely at the page. They really need to update that diagram.
I personally don’t like the 6N138, I always use 4N35 chips and use Teensy extensively with no issues. But I’m glad you found your issue with the 6N138
I’ve heard people say that the 6N138 is not as fast as it could be. I’d be very curious to know more about why you prefer the 4N35 and specifically what your input circuit looks like for use with a teens 4.x
For me it just works every time, when I follow other people’s designs and use a 6N138 I usually have problems, so I switch it out for a 4N35. I know it’s going to work.
Check out my GitHub pages, many Teensy based projects in there including an 8 note 16 bit polyphonic midi to CV converter which ironically shows 6N138 but that’s an old schematic in easyEDA as newer ones are on Kicad.
1 Like
I took a look through some of your code - looks like you and I are working on very similar stuff! I’m guessing we both cribbed a bit from elkayem. I’m using a very similar circuit to his, and re-using certain aspects of his code like the encoder controls and some his techniques for managing the menu system and calculating the right dac output values.
Awesome that you made yours polyphonic - that’s a whole problem I just don’t have it in me to tackle at the moment.
Well I stole the TSynth polyphonic routine and just substituted the audio library with DAC and gate/trigger updates, it was my first project back in 2020 when this was all new to me.
I built a 6 note poly 12 bit MIDI to CV after blowing up a commercial one that I had bought on ebay and because of COVID I couldn’t get much help from the German designer, so I thought why not try and make my own. This was then upgraded to 16 bits and then 8 note and finally an 8 note poly with autotune of the 16 VCO’s.
1 Like
ahahah wow I just read through this thread and saw that I had literally the exact same problem with the exact same solution 4 years ago. If I’d re-read my own thread I coulda saved hours. I’m finna drive to Paul Stoffregen’s house and beg him to update that diagram
1 Like
ProTip: when you bookmark a post on here, you can set a date/time (say perhaps … 4 years in the future?) to be reminded of it.
3 Likes
Just realized, I never posted my results. Here is V2 of the project, the video description also has links to my github with all the code and PCB files. This project still isn’t fully 100% where I’d like it to be but I think it’s a very marked improvement from V1, and is totally useable.
3 Likes
The new Teensy is sort of amazing. Similarly, I’ve been throwing around the idea of doing a Kosmo conversion of the newish Teensy 4.1 version of the eurorack Ornament & Crime module - since it’s open source and crams a cubic buttload of utility into a relatively small package. Evidently the new hardware can also handle Audio DSP
2 Likes