Closed yatli closed 3 years ago
To eval the idea I'll implement file server and usb midi.
it would be good if the pc side application ran as a vst.
it would be good if the pc side application ran as a vst.
Windows only?
it would be good if the pc side application ran as a vst.
Windows only?
I hope not :grin:
Then this: https://juce.com/ ?
Yep. that's what I was thinking.
Been a while since i've looked into vst multi platform tech.
Did your ISP just accidentally turn the "retrig" knob? :D
... or make it a VST host?
MD -> Kit Edit -> scroll down to the VST menu
finished the ack/resend/timeout transportation layer. MegaCom is half-duplex so it's easier than Tcp( will test with a hello world server tomorrow.
couldn't get UART0 RX interrupt to work... thoughts?
The UART0 ISRs are being managed by the Arduino serial libraries.
It's how Serial.begin works.
See:
./HardwareSerial0.cpp
couldn't get UART0 RX interrupt to work... thoughts?
please disregard. it doesn't work because non of the tools I tried work at 250kbps sending hex (
The arduino serial monitor does allow me to reach the ISR, but no hex input. The other tools I tried (moserial, YAT, minicom) either doesn't have hex, or doesn't support 250kbps
Even works when the sequencer is running. Fully asynchronous.
Fact: running the sequencer at the grid page, file download speed = sorta 20KB/s It gets more bandwidth when opening the setting page and navigate to SYSTEM with only 2 entries displayed, or the CHROMATIC page which is lazily drawn :D :D :D
Funny. I got a steady repro of the BPM drifting problem (while transferring file):
Sounds the like the serial ISR is hogging the cpu not allowing the MIDI or TIMER ISRS to execute. Lowering the baud will probably solve this.
It also raises tempo without file transferring. What kind of magic is this 🤔
If you don't enable*** all ISR sei()
before the sequencer ISR runs, same thing happens. The tempo increases.
This is likely because the clock counters are not increasing.
So perhaps something similar is happening here?
oh ok. so it's like, something in the menu system blocked the ISR for a bit of time?
Shouldn't be.
The only thing blocking the timer IRSs should be other ISRs or if you explicitly disable interrupts in your code.
Is data hitting UART0 when idle?
no. ISR standing by.
you sure?
yeah pretty sure. host is doing nothing if I don't click the UI.
My suspicion is that one of your conditional statements is passing unexpectedly and is triggering a call to the ring buffer code that is using USE_LOCK() / SET_LOCK()
--
Or there is continuous data on the UART0 causing the isr to be triggered.
Let me try this on the dev branch.
That's a repro. dev branch. :p
That's a repro. dev branch. :p
You seeing tempo drift in dev branch?
Yeah. Just do a few rounds of the menu thing.
Yeah. Just do a few rounds of the menu thing.
do what now?
Just flashed dev branch. I'm not seeing any tempo drift. (from grid page tempo display)
When MENU -> MD settings are changed. Global settings are sent back to the MD. This includes tempo.
I think there is an edge case where the global settings tempo, is not up to date, so the MD tempo gets shifted to an older value... instead of current.
Not likely. Why does it keep increasing?
I'm not seeing the increase you're reporting then.
A simpler repro without involving the GridPage init/cleanup:
Not showing up for me.
Justins-MacBook-Pro-4:megacommand jmammarella$ md5 main.hex
MD5 (main.hex) = bc67731518f844109024bbdf1be6a3c0
Justins-MacBook-Pro-4:megacommand jmammarella$ git status . | head -n 20
On branch dev
Untracked files:
Justins-MacBook-Pro-4:megacommand jmammarella$ git log | head -n 20
commit cf7b6e5ca351760162b5e785b4dc34a2b6e5e5e2
Merge: 4408431 73dd675
Author: jmamma <jmamma@gmail.com>
Date: Tue Aug 11 12:36:09 2020 +1000
Merge pull request #125 from jmamma/size_reduce_2
Size reduce attempt 2
Alright. Same as the last time I opened the case. We can discard the issue here I guess.
What happened last time ?
Bad compile ?
The timeline:
So, just some weird states going on in my MD. Maybe related to other issues (last time it was https://github.com/jmamma/MIDICtrl20_MegaCommand/issues/98)
Porting https://github.com/v-yadli/paw-01 over to test realtime messages.
What is/was paw-01?
Oh that.
A synth that browses the internet(
Is that a DAW or a 💣?
which red wire again?
Took me quite a while to make it stable and not dropping frames, but here it is, a 1x2 midi bridge.
Host: https://github.com/yatli/Camelotia/tree/main/src/MegaCom.MidiHost
Requires two virtual midi devices, "MegaCommandPort1" and "MegaCommandPort2"
Also, debug messages are framed into one kind of message. So the debugging capabilities can be retained (or even improved)
With megacom framed debug (and custom formatter): Sketch uses 221460 bytes (87%) of program storage space. Maximum is 253952 bytes.
With standard Serial.print, upstream dev
branch:
Sketch uses 218962 bytes (86%) of program storage space. Maximum is 253952 bytes.
(Cannot compile megacom-enabled debug version with Serial because of uart0 conflicts)
Hook up the midi host and debug:
Work in progress. We can build a lot of things upon this: