Search:

Thanks very much. Can you please explain this line:

>> only other is a T_4.0 not lockable chosen as I needed battery pins)

How does the lockable version preclude the use of battery pins...

Somewhat related to this question, is lockable Teensy more vulnerable to being bricked regardless of whether it has a key programmed? Is it the key fuse map itself that is prone to being overwritten...

Yes the T4.1 would be locked, so using ehex not hex files. I'm looking for a way to allow an end-user update the firmware in a locked T4.1 using a simple stand-alone program like TyUploader, without...

I have a need for end users to be able to update firmware on T4.1 using a simple stand-alone tool like TyTools / TyUploader, and without pressing the reset button (which isn't accessible).
...

Just an update for anyone else looking to replace the T3.6 with its onboard DAC by using T4.x and the PT8211, especially for projects that require asynchronous data writes.

By using the bit...

Thanks for the MQS details Paul. Unfortunately if it's not well suited to variable sampling times it's not going to work for me anyway. So I'll try the PT8211, possibly with a LPF after its output....

One forum member in the other thread you mention was very negative about the PT8211, saying it was worse than the T4 "medium-quality-audio" output. Is that to your knowledge the general consensus...

Fabulous! Thanks very much. Looks like this approach should solve my problem and allow me to migrate my T3.6 project (that needs variable DAC write times) to T4.1. Are you using the PJRC PT8211 board...

Thanks for this. Do you happen to have examples, either audio or FFT displays, of the improved harmonic content and aliasing for this versus the BLIT or polyBLEP approaches?

Thanks agian Paul. I dusted off my oscilloscope to check the signals I was generating with that code, and discovered the DIN streams were still not setting higher bits. There must be a problem with...

I realized later that the reverse bit order might actually be enough to cause the result you showed due to the fact that the saw wav is incremented in steps of 160. Normally that would cause the...

Thanks Paul, all much appreciated (and sorry about the mix up with the other Paul). I rechecked the code above and realized it's sending the wrong bit order as well as having one value wrong in the...

I had another read of the data sheet, and now think any WS edge might terminate the data input sequence for a channel. Even though that seems to contradict the statement that only the 'first 16 bit...

Paul , here's a first go at a test program that sends 100 and 200Hz sawtooth waves to R and L channels respectively.

I'm assuming the rudimentary timing diagram in the PT8211 data sheet is...

p.s. How would you rate the audio quality (and background noise) you get from the PT8211 board vs a T3.6 DAC, when powered by USB (perhaps with an isolator)?

Thanks Paul, I too was thinking it might be a simple enough chip for this to work. It would be great if you could do a quick test for me, as indeed I don't have a PT8211 board (they seem not...

For some time now I've been trying to find a way to have a continuously variable output sampling rate solution for T4.x to take the place of the ever more precarious T3.6 situation.
While adding a...

Yes, I've looked at Stefan's papers in the past. I was hoping to get around to trying out some of his ideas but haven't yet, and they're not trivial to implement if I remember correctly.

Thanks very much for the code examples in this thread, which I have used to send single L/R sample pairs from a T4.0 to the audio shield DAC in my application. Is it possible to modify this so that...

I discovered that my problem was due to the need to comment out the flush command in usb.c to get sysex to behave correctly., as discussed in this thread:...

Hi Paul,

I came back to check this issue today with your new usb_midi.c file copied into the T4 cores folder, and using the simple test code I posted previously:



void setup()
{
}
int n=0;

Thanks very much Paul, that's great. It seems to be working as it should now from my tests so far.

Thanks for that idea. Unfortunately I would like to be able to have more than two devices as well.

What kind of changes to usb_desc.h do you suggest I try? Or better still, would it be possible...

I am using 2 identical midi devices based on Teensy 3.6, and compiled identical code for the two except for different names ("GND-1" and "GND-1 B") using the MIDI_NAME method. But if I have both...

Just an update to say these are no longer available.

I am migrating a project to T4, and so have 20x Teensy 3.6 boards without headers available for sale. They are in sealed packets with pin-out cards.

The price per board is the same as what I paid...

Thanks for running the tests. Your findings are exactly the same as mine.

Paul, is there any chance you could look into this?

Thanks for the reply. Can you try my simple sketch with your isolator and a midi monitoring software (ideally MIDI OX if you're on windows)? Given the T4 appears to be sending at 480Mbps, the...

Thanks Paul, unfortunately when I uncommented that line in the (core) usb.c file, the MIDI data sent from the Teensy to the computer were corrupted both with and without the isolator. Note also that...

I am migrating an audio project from T3.6 to T4, and have run into a problem in relation to USB isolators. I don't need high rates as I'm only transferring midi data, and have been using an...

Thanks very much, that's exactly what I need.

I have code developed on T3.6 that I would like to migrate to T4.0 / 4.1. In that code I use 3 interval timers, one at 10ms, one at 1ms, and one at a variable audio sampling rate up to about...

So it's a year down the track and I have my project running very nicely on a Teensy 3.6. But the board is now out of stock everywhere, so I'm looking or possible alternatives. And the extra CPU power...

Here is the solution that works for me on T3.6. Rather than commenting out the midi_flush_output line as suggested before, add a variable at the top of the usb_midi.c that is used to notify the flush...

Here is the solution that works for me on T3.6. Rather than commenting out the midi_flush_output line as suggested before, add a variable at the top of the usb_midi.c that is used to notify the flush...

After more thorough testing, it seems this is not a good solution because some of my other midi USB functions misbehaved (badly) after making the change. It seems we need the change specifically for...

After more thorough testing, it seems this is not a good solution because some of my other midi USB functions misbehaved (badly) after making the change. It seems we need the change specifically for...

I received information from h4yn0nnym0u5e via the other thread about how to apply Rolfdegen's change to the library for Teensy 3.

In short, what is needed is to comment out line 957 of...

Excellent, thanks very much. And yes, it fixed my problem on T3.6 too, so thank you Rolf also!

Paul, (if you see this) are you able to make use of these findings for T3 & T4 to improve the...

I can confirm that if I send the sysex out of the Teensy using serial midi over a 5-pin DIN cable, rather than USB, everything works just fine. In that case I used an external device to translate the...

This is cross posted from a thread in the general discussion about a Teensy 4.1 issue: https://forum.pjrc.com/threads/70288-usbMIDI-transmission-error?p=311329#post311329

But for my purposes it...

Even running absolutely nothing but a sysex dump in a simple sketch I get errors on Teensy 3.6 with midi Ox.

Here is my code, using a button press on pin 2 to start a dump. It should show 50000...

Thanks for the thread. I have a very similar problem, but on Teensy 3.6 (using midi Ox). My synth's sysex messages are about 1200 bytes long, and after adjusting max limits in the library files, I...

Thanks Kurt,

I'll have a think about how to capture a stream that produces the host port data loss so it can be reproduced without the midi controller.

Cheers,
Richard

I just tried the simple example on a Teensy 4.0 and get the same result as with the T3.6, with missing note events if I simultaneously vary the modwheel touchpad rapidly on the minilab.

So perhaps...

p.s. if anyone else happens to have an Arturia Minilab II and is willing to try the above example code whilst playing notes and sweeping the modwheel slider it would be good to get verification of...

Thanks Mark, yes I had seen those threads and have tried that. Unfortunately it makes no difference with my issue.

I tried overclocking the T36 at 240Mhz (rather than 180Mhz) but it didn't solve my problem.

Thanks Mark,

I very much appreciate any and all suggestions, as I'd really like to have the option of connecting controllers to my synth without a computer. But this is a synth I'd like to make...

I have not been able to make the Arturia minilab II work reliably with midi via the USB host port, so it seems the T36 host lib as it stands cannot be used in midi products that would be released to...