Search results

If you do write a new one, please consider musically useful API features like play direction (forward, reverse), auto-looping or one-shot playback, playback start point, playback endpoint, and synchronized start/stop. This could put the Teensy on par with something like the Tsunami wav trigger...

Could you try powering the receiving T4.1 from its own 5V supply? In other words, only D+, D-, and Gnd should be connected between host and receiver. The reason I suggest this is I don't know the characteristics of the 5V USB supply on the host T4.1, so perhaps it's not sufficient for powering...

You might take a look here for some inspiration, not sure if it's tested but on first glance looks okay: https://github.com/MarkzP/AudioEffectDynamics

Could be a power problem, maybe try the delay before usbHost.begin()?

Interesting. My receiver was actually a T3.6 because that's what I had handy. I will try to scrounge up a T4 to use as the receiver, but gotta work now.

Are you sure the USB cable plugged into the client T4.1 is a data+power USB cable? I don't mean the 4 pin host cable, I mean the device cable. On 2 different occasions I've had power-only cables sneak onto my bench and wasted a bunch of my time trying to figure out why stuff wasn't working...

I'm using platformio, so my setting is "build_flags = -DUSB_MIDI_SERIAL". I suppose you're using the arduino IDE, so I can't tell you where/what to select there. However, if it's not selected correctly, the code will not even compile, so I doubt very much that's the issue. The two USB Host...

Host code: #include <Arduino.h> #include "USBHost_t36.h" USBHost usbHost; MIDIDevice usbHostMidi(usbHost); elapsedMillis wait; void setup() { usbHost.begin(); } void loop() { // USB host usbHost.Task(); usbHostMidi.read(); // send something every 1 second if(wait >...

Very difficult to follow your post regarding who's doing the sending and who's doing the receiving, but it appears you missed usbMIDI.read(); inside the loop() of the code snippet. It may also be better not to use delay() in your loop() because it might (?) block execution of other code that we...

So are you asking how to measure a tiny voltage? Or something else?

I believe you missed myusb.Task() inside your loop() in the "host" code. Also if you could wrap your source code in code tags next time, it would be a lot easier to read.

Weird, yeah don't add a DC offset to any speaker. That's a bad idea.

What do you mean by "ride"?

If you share your code on github or something, it would be a lot easier to offer suggestions. Although, the Linnstrument is really expensive so it might be hard to find people who actually have one to do "real" development with.

What a cool idea, great job. Never seen the Linnstrument until now. When you say you're looking for help/collaborators, what kind of help do you need?

That was for my envelope code, which has nothing to do with john-mike's code.

Apologies for bumping this old thread, but here is another granular pitch shifter implementation: https://github.com/pichenettes/eurorack/blob/master/clouds/dsp/fx/pitch_shifter.h It blends or interpolates the grains for a somewhat better result. This technique could be applied to the existing...

Thanks a ton, I will give this chip a try :) It's the cheapest way I've seen thus far to get this many channels.

Hey there, sorry to revive your old thread, I was just curious about your DAC setup. Are you using the PCM1681, did it work straight away in I2S mode? Could you share any more code/info about it? Thanks.

It sounds like you're making a Daisy-style board... very intriguing.

The T4 MM would go into my custom hardware. I want to be able to position the USB host and device connectors and uSD connector wherever I want, and use whichever connector style I want. That can be done now of course, but would require little USB jumper cables and so on to achieve it. Fine for...

True, I had forgotten about the supply strain on the bootloader chips. I suppose there's still hope :)

I didn't anticipate the T4 MicroMod to actually be manufactured by sparkfun. The radio silence since the git commits and blog posts in October could indicate one or both parties lost interest, or maybe SF is just too busy or waiting on parts, who knows. *sigh*

Do you anticipate certain issues due to the density? My eyes are still good enough to solder it.

I really like the idea of a T4 MicroMod and hope that it sees the light of day. :)

Here's how I adapted the Mutable Instruments envelopes to work with the Audio library: https://gist.github.com/wcalvert/2a5b5f1c9d0d4066cab27fa6ac526a60 I started with Pichinette's python code to generate the lookup tables, but I used floats in my LUTs...

Sounds awesome, great job!

The Audio library is heavily dependent upon the specific microcontrollers that are used in the different 3.x and 4.x boards, and doesn't support any 8 bit chips. The Mozzi project does support 8 bit chips, I've never used it though: https://sensorium.github.io/Mozzi/ Good luck

Aha, thank you Paul.

Could anyone explain the 0 ohm jumper and the address jumpers on the updated 4.x CS42448 PCB? Without a schematic I'm not sure of their intended usage.

The first requirement is that an RTOS would need to be ported/supported fort the 1170 and (possibly?) integrated into Paul's Arduino implementation. Then you would be able to create tasks and assign them to one core or the other. You would still have a single setup() and loop(). See here for...

I think your question is too vague for anyone to really help you. If you let us know what device you want to connect to the T4, there might already be a library out there that can help you.

Regarding the failure to upload to T4, I just wanted to share the following. It is not a bug report and I'm not expecting anyone to do anything about it. It should be treated as anecdotal only. I have been building a device around the T4 for a while. The T4 has its VIN trace cut, and this...

You can share the same I2C bus as long as the devices have different addresses. Mouse example code here: https://www.pjrc.com/teensy/td_mouse.html If you don't have the datasheets for the I2C devices that you salvaged, project will be dead in the water.

My guess is you're reading/writing out of bounds on one of the several arrays that you've got. One recommendation is to #define the array length so you can be sure any code which accesses the array has a proper length available. For example: #define NUM_VOICES 8 AudioSynthWaveform...

When using the analog pins with the Audio library, the Audio library code pretty much takes full control of the analog hardware, so calling analogReference() probably does not do anything. Your code isn't actually changing the roomsize or damping... if you are recompiling and reflashing to...

DAC8565 support in the Audio library would be cool. I suspect the reason the original author didn't go that route is latency. Each block in your audio chain will add about 3 milliseconds to the end-to-end latency. The stock O&C firmware claims 100 microseconds of latency...

O&C runs its own special firmware that doesn't use the Audio library, so it has no USB to Audio abilities .. unless there is a firmware fork that I don't know about. Anyway, let's pretend there is a firmware fork that uses the Audio library. The Audio library supports stereo USB audio only, no...

Please don't modify safety critical stuff on your car.

Right, it's not the case. The '&' means "address of". So for the following line of code: AudioPlaySdWav *players[NUM_PLAYERS] = {&playWav1, &playWav2, &playWav3, &playWav4, &playWav5}; In English we might say something like "make an array of pointers, the first pointer will point to the address...

Hmm, so is the crossfading started by a user pressing a button or something? What should happen if the user presses the button too rapidly for the crossfading to complete on whatever is currently playing?

I'm sorry, I think I should have read your code more closely. I was misunderstanding how you were intending to use your class instances. I think your approach is fine for multiple instances.

Every time you call phase(), the phase accumulator gets reset. See here, line 53: https://github.com/PaulStoffregen/Audio/blob/master/synth_sine.h My best guess without testing your code is: your idea might work if you only call phase() when the knob position has changed. To do that, just keep...

Basically you would need to have different class definitions, how else would your class be able to work with other patchCords, mixers, and filters? If you use pointers for members, you can reuse the same class definition by passing in pointers to different objects like so: AudioFilteredMixer...

If you only need one instance of AudioFilteredMixer per project, that approach will work fine. If you need multiple instances, you'll probably want to switch over to using pointers for your members.

IMHO you need to first identify exactly what your goals are, and I can see two possibilities: 1: you are trying to make a wrapper class to encapsulate existing functionality of the mixer and filter for some purpose or another, or 2: you want to make a new class of Audio object that can be reused...

You can do something like this if you want the logic to be a little more compact and easier to maintain. #define NUM_PLAYERS 5 PlaySdWav *players[NUM_PLAYERS] = { &playWav1, &playWav2, &playWav3, &playWav4, &playWav5 }; void playFile(const char *filename) { for(int i=0; i<NUM_PLAYERS; i++)...

It might compile and work correctly, but it's going to make a very poor piano due to lack of multiple voices and/or oscillators, no envelope generator, filter, etc.

Almost none of the Audio library will compile for the LC. It would be wiser to choose a 3.x or 4.0 if you actually want to synthesize sounds. You'll need to connect analog output from a DAC or codec to the amplifier's input.

22kHz sample rate means the maximum frequency that can be reconstructed is 11kHz. Google for Nyquist sampling theorem or Nyquist rate for more info.