Search results

Isn't Bela's claims about its audio latency? I didn't see anything about low MIDI latency on their pages. Unresponsive continuous controllers in DIY projects are often from excessive signal filtering or naive handling of the MIDI messages in the code. The delays will be tens of milliseconds...

....which I think means you have to provide a 'graph' for a plausible transfer function that (soft) clips. The array you need will have a plateau at or near -1 at the start and at or near 1 near the end with a steeper than 45 linear segment and possibly some softening around the knees between...

So... a clock isn't channel specific so you'd have to use two cables? Virtual in this case? https://www.pjrc.com/teensy/td_midi.html I've never used them but this statement from the library page makes me think it's feasible. But I don't have direct experience with cables as I've never had the...

Sorry... I don't really know the audio library and I didn't read your post carefully.

Typically when a filter cutoff is modulated by pitch it's normalized relative to one half the sample rate and then some parameter for slope. You might also want an offset to move the cutoff from the fundamental.

The terms 'host' and 'device' modify USB and not really MIDI. Unless you're trying to host a MIDI-controller via USB you don't need to worry about the 'host'. (And if you are maybe start with a simple controller project first :) )

While not qualified to say, what I read is the 137 can tolerate a much higher impedance pullup and so the using the internal one makes sense to me. I believe lower value pullups would still work and that higher values are recommended to mitigate high-frequency noise from the fast switching...

This suggests to me you might be overflowing the MIDI buffer on your PC and the USB linkage is what is crashing. EDIT - looks like you are sending messages on every loop. You need to send only if different from the previous to avoid MIDI overload.

Certainly 'quantizing' doesn't really capture the issue either. Trying to put together the above reply I noticed how unclear the answer was musically too. It depends on what the 'signal' you are starting with is like I guess. Mapping seems to me what OP is looking for. It might be he's...

Get the modulo of the MIDI by 12 and use the result as an offset to map each scale. Each scale is just a 12 value array saying how to shift to allowed notes from each non-allowed offset from the tonic. Then restore the octave multiplying by 12 again. uint8_t intervalArray[7] =...

There are many examples available. Decide what you want it to do EXACTLY and spell it out in full detail. Will the same message on ever press work or do you need it to toggle states? Many button examples show note on/off messages on the press and release. Your software may be fine with...

If all you want is to power the light when connected to USB power you can just run the LED in series with a resistor from the power (5v / Vcc) to the ground. (You need to get the LED connected in the correct direction!) A controlled LED is just the same but powered from an output pin that can...

yes. If you were buying then you'd want a Teensy LC as the cheapest available but if you already have one any Teensy can do this no... it's 8-bit but that doesn't matter for OS support which is thru the Arduino/Teensyduino software Either will work, you would just change the logic of what the...

You mean like an expression, wah, or volume pedal used with musical instruments? Search 'wah wah enclosure' but they are pricey and hard to find. M-Audio EXP1 expression pedal can often be cheaper than an empty case but the room inside is limited. Dead Cry Baby wah wah pedals are sometimes...

If it's not your code what would it be? Teensy run many, many, many times faster than a Nano and so buttons need to be debounced more carefully. Another possibility is not clearing the MIDI queue for incoming MIDI. That could explain only some 'getting stuck' if they are sending MIDI...

As someone reminded me recently the default behaviour of serial MIDI is to merge any output with any incoming messages, so each should be able to connect via Tx to Rx whether you do the MIDI isolation scheme or just connect them with a shared ground. (Each Teensy acts as a repeater for the...

Yes, merge must be done in software but 'thru' ports can just buffer the input signal. It's to allow a master controller daisy chain sound moduals. I was responding to the idea you could drive the port without a buffer but I didn't notice they mean to have a 'merge' output not a 'thru.'

I think you need to add some buffer (e.g. feed both sides of an AND gate or back-to-back NOT gates). A merge out should be feasible but I don't do serial MIDI much and can't recall how easy it really is.

+1 It's a bit too much guesswork about your scale and octave system with code fragments (the rule is to post complete code) but I would expect it better to do the octave shift on a variable that is then used in a single note-on and the same variable in the note-off. If the octave can change...

Then this should work... // initialize the bounce objects Bounce digital[] = { Bounce(DIGITAL_PINS[0], BOUNCE_TIME), Bounce(DIGITAL_PINS[1], BOUNCE_TIME), Bounce(DIGITAL_PINS[2], BOUNCE_TIME), Bounce(DIGITAL_PINS[3], BOUNCE_TIME), Bounce(DIGITAL_PINS[4], BOUNCE_TIME)...

If you're actually using pins 14 and 15 you need to fix this too: const int DIGITAL_PINS[D_PINS] = {0,1,2,3,4,5,6,7,8,9,10,11,12,13,16,17,18,19,20,21}; and D_PINS = 22 And if you're really using 0 - n pins in order you could just skip the DIGITAL_PINS array and put the number in directly...

I see now... DIGITAL_PINS[16] is going to reference pin 18 as '16' is the position in the array and not the pin number inside the array. Your pin and array index values start the same but they are not the same. Just keep going in the numbering here 14 to 19 (the number of pins minus one, zero...

Somewhere in here perhaps ;) I was disappointed when I couldn't figure out how to make this part of the code responsive to changes in the number of inputs. Since then someone posted how it's done in an unrelated topic but I've not integrated it into this code.

Looks right to me. And LC is the obvious choice for MIDI out of the current line-up because it's the lowest cost. MIDI is not very demanding of resources and human interactions with controls are glacial in timescale compared with the speed at which T3.x run. Changing the buttons to Control...

So what are you saying about values other than 1023... it sounds like you have hardware problems.

int velocity = map(piezo[i], thresholdMin, 1023, 80, 127); You want peak[i] not piezo[i] here. You're taking the last reading instead of the maximum reading... as it's likely below the threshold min and map doesn't deal with out of range inputs well (I recall but that might not be true for...

int velocity = map(peak[i], thresholdMin, 1023, 1, 127); Serial.println (velocity); usbMIDI.sendNoteOn(note[i], velocity, channel); Yeah, how can you be getting those values at all? If you are then the MIDI likely would max out at 127 (I've never tried to overload it or ever...

I've not been following the form closely of late... but I recall seeing something where the host wasn't packaging MIDI efficiently and a fix is in the works??? (looking to see if I've imagined this...) rummage rummage… edit...

It works, sounds ok and doesn't seem to damage anything but you should never ever use the phone jack as a line out because... er, it's wrong? ;)

Yeah... a search suggests I have it wrong on fast write.... good luck.

I was hoping someone qualified would reply. I think you should not use digitalWriteFast as I believe it's meant for compatibility only in Teensyduino. I think you need not worry too much about the serial exchange speed given normal MIDI latencies. Is there a reason you're not running the...

I get why Pete's code it preferable but it looks functionally equivalent to me... looked to me like your modulo math should do the same thing in resetting on reaching the inter-accent count (ie -- every three steps) I don't think it matters if you have what you need but I don't think I ever...

My bad... lots wrong with the theory beside being incorrect. It would not compile, and it would not explain the result.... doesn't this really imply it's resetting because it's getting a start message that is stopping it from continuing uninterrupted? If you add a print message there you'll...

I think you are missing the setHandleStart() in setup so that handleStart is called when an start message is recieved. https://fortyseveneffects.github.io/arduino_midi_library/a00039.html#a6aa08e1f81d063d78ecea8995252e858 This is covered better on the USB MIDI page under "Receiving Messages...

Not sure I understand the problem... you want the accent on the third pulse? if (accentPattern == 0) velocity = accentVelocity; // we want it on this step accentPattern++; But your test is looking for the 1st (index zero!) ... If you want that third then...

Using filtering to pass all but the three-byte stuff appears to pass everything else so you'd only need to handle the basic messages from the controller and in the process alter the the note values on note on/off messages. But I think the slick way would be to alter the library itself at this...

https://github.com/FortySevenEffects/arduino_midi_library I think you call turnThruOff() during setup. But then you have to pass all the other stuff manually if you want the other MIDI to pass unaffected.

...er… how can an optocoupler work if reversed? Is that possible?

Those two messages are only different from what you're expecting by the note values... are you sure it pulses middle-C (note=60)? edit... I didn't notice they both say 'off'

Untested code changes... not even compiled so there may well be an error or two! /************LIBRARIES USED************** // include the ResponsiveAnalogRead library for analog smoothing #include <ResponsiveAnalogRead.h> // include the Bounce library for 'de-bouncing' switches -- removing...

I'm writing a more detailed reply but in the meantime… you are assuming some things that are just names have meaning to the compiler. CCID is just the name of an array of data... so is notes… It really should just be the MIDI call you make that's different and the error you are really having...

// initialize the ReponsiveAnalogRead objects ResponsiveAnalogRead analog[]{ {A14,true} };This also should work and is likely what you were attempting. With this the defined constants are not needed. Note you should use A14 as analog pin numbering. I think AnalogRead() will use A14 if you...

ok.... since that's my code you're starting with and the project is certainly worthy so I guess I should step up. Not sure why you're using Many Knobs... for one knob and one button. But here's your problem (I think... it's late and I'm prone to error) The pin assignment has been overridden...

I think that's supposed to be from the greater high-frequency content -- which entails greater power levels. It's only going to be a factor at levels already near the physical limits of the speaker to dissipate heat. Use the Peak object... it's not averaging but returning the highest level in...

Yeah sorry... like I said I didn't compile. I used a different name for the ON value being sent. usbMIDI.sendControlChange(note[i], ON_VELOCITY, channel); Change this line by replacing 'ON_VELOCITY' with 'ON_VALUE' since we are not sending a note velocity but CC value.

You have three switches and two wires to your Teensy? Assuming you know what you're doing with the wiring here's the above code with the digital section altered to CC messages and the analog stuff removed. // include the Bounce library for 'de-bouncing' switches -- removing electrical chatter...

What this guy was doing is pretty specific... ...maybe spell out what YOU are trying to do and I'll see if I can help :)

My post had some additional stuff in it that was somewhat confused because I forgot you were making a synth and not a controller. Are you short of memory? I would think keeping it all in an array (with two dimensions - patch and parameter) and reloading it at setup and writing to EEPROM only...

If these are always in sequence, why do you need them in an array? Why not just add one or two to the first parameter's address for the second and third parameters when you dereference them?

It does stereo in and out but only one MIC level input. With a two-channel preamp you could address the gain issue and use both line-level inputs... but listen to experts on how and not me. ;) Also, the ADC on the audio board is OK quality but not very impressive specs. There are third-party...