Add network support by omersiar #747
Conversation
Add network support
|
Build for testing: |
|
https://github.com/dwhinham/mt32-pi/wiki/Networking%3A-RTP-MIDI-%28AppleMIDI%29 says
In the meantime, the awesome @rsta2 has implemented this. Do you think you could incorporate it?
This means that we could advertise both RTP-MIDI and FTP (if enabled) on the network, making it much simpler to connect (without having to remember the IP address). |
|
Build for testing: |
|
One can already connect to minidexed by its hostname (defaults to "minidexed") if the router supports home network domain. |
|
Yes, but that won't cause it to show up in music or FTP applications on the PC/Mac automagically. So far we are not using the mdns publisher in MiniDexed yet at all, so it would be a matter of porting it over from https://github.com/rsta2/circle/tree/master/test/mdns-publisher. Probably something for a later/separate pull request? |
|
Oh sorry I meant the circle as a submodule. Currently minidexed do not checkout to required point for <circle/net/mdnspublisher.h> |
|
Probably have to adjust https://github.com/probonopd/MiniDexed/blob/main/submod.sh so that the needed branch/commit is checked out? We are using this script since editing git submodules on the GitHub web interface is less than user friendly. |
|
Yeah this ⬆️, but changing this can break things. Let me check if latest circle release does break anything. |
|
Testing on a Windows 11 PC: After the usual it says (Minor nitpick: The Trying to connect via FTP from the FTP client built into Windows, I cannot get a connection using I do see a Now I'll move on to testing the MIDI aspects... |
|
It compiles with Step48 with these warnings: net/ftpworker.cpp: In member function 'bool CFTPWorker::_ZN10CFTPWorker4PortEPKc.part.0(const char*)':
net/ftpworker.cpp:464:9: warning: 'char* strncpy(char*, const char*, size_t)' specified bound 512 equals destination size [-Wstringop-truncation]
464 | strncpy(Buffer, pArgs, sizeof(Buffer));
| ~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
net/ftpworker.cpp: In member function 'const TDirectoryListEntry* CFTPWorker::BuildDirectoryList(size_t&) const':
net/ftpworker.cpp:363:11: warning: 'char* strncpy(char*, const char*, size_t)' specified bound 6 equals destination size [-Wstringop-truncation]
363 | strncpy(VolumeName, VolumeNames[i], sizeof(VolumeName));
| ~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
minidexed.cpp: In member function 'void CMiniDexed::SetVoiceName(std::string, unsigned int)':
minidexed.cpp:1656:9: warning: 'char* strncpy(char*, const char*, size_t)' specified bound 10 equals destination size [-Wstringop-truncation]
1656 | strncpy(Name, VoiceName.c_str(),10);
| ~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~
../Synth_Dexed/src/dexed.cpp: In member function 'void Dexed::setName(char*)':
../Synth_Dexed/src/dexed.cpp:1699:10: warning: 'char* strncpy(char*, const char*, size_t)' output may be truncated copying 10 bytes from a string of length 155 [-Wstringop-truncation]
1699 | strncpy(name, (char*)&data[DEXED_VOICE_OFFSET + DEXED_NAME], 10);
| ~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
I wanted to give impression that this is not stuck and move the encoder one step to see actual menu. Dirty hack. |
|
Yes, I understand your concerns @diyelectromusic. I view this whole networking code as an opt-in feature that should, if switched off, have no impact. So that whenever an issue comes up, we can compare with networking switched off. I've tested this quite a bit over the last days. And no, I don't advise on uploading files over FTP during a live performance ;-) |
|
Build for testing: |
|
Ok, so it would appear (according to the Scheduler documentation in Circle) that the non-pre-emptive, cooperative multitasking scheduler will only ever work on core 0 in a multi-core system... So in that case, these networking tasks cannot interfere with the audio DSP side of things which all happen on cores 1,2 and 3. Any potential issues will be in things like UI handling and handling of non-networked MIDI, so it would be good to know if the USB and serial MIDI handling are affected by the networking; and then how the UI functions whilst the networking is running. Aside: I think this call to ->Yield() probably shouldn't be there - this is in the non-multicore (so Pi V1) area of code: I'm also not clear why there are so many calls to Yield in the CMiniDexed::Process() - e.g. in every part of the performance file handling. Was this to fix some issues that have been found with the scheduling? I really think this needs some developer documentation adding to the wiki to explain how the CTask and CScheduler facilities of circle are being used to support the networking. I'd also like to see more checks/comments in the networking code to make it clear what is called when and to make sure things will drop out if things aren't properly initialised. There seems to be a few assumptions about order and call sequences to ensure that the networking isn't enabled when not configured. Should any of this sequencing change in the future (I don't know why it would, but things do shuffle around with time) then those assumptions would break. Another Aside: I think printf() was used in mididevice.cpp as LOGNOTE doesn't always work in all contexts - e.g. if called from a serial port interrupt or something like that - I forget exactly... (although I'm not sure those printfs are particularly useful in there anymore anyway...) I'm not sure I quite follow the logic in CMiniDexed::UpdateNetwork() - is that just performing the network startup? If so, why is it called for every scan of Process()? I'm not following the interplay between bNetIsRunning, m_bNetworkInit, and m_bNetworkReady - can we make this a proper state machine if these are states the system passes through - and are these states appearing on separate calls to UpdateNetwork() or are they all expected to happen within the same call? Are those LOGPANIC calls really the most appropriate response to a networking issue? Also, response to various other bits of the networking failing seem inconsistent (there is no checking at all for m_UDPMIDI.Initialize() for example). btw - should we be saying "applemidi" - wouldn't it be better to say rtpmidi... (and we'd not be building someone else's company name into the source of an open project...)? There seem to be some build updates as part of these changes that don't seem specific to this change? I've mentioned before that I'm really not a fan of on-the-fly patching of major source files. If you really want to build the git hash into the firmware, can we put it in its own include file or something so we're not trying to patch userinterface.cpp? Wouldn't need a s// then either - just echo it out to the file. (isn't "." a wildcard anyway? So wouldn't this actually patch every occurrence of the string "Loading" and any following three characters no matter what they are? Which could even include a newline and the start of the next line iirc...) As I say, I've not been able to follow the networking code itself, I've just tried to think through any ramifications for the core MiniDexed functionality... Kevin |
|
If we already have wifi, ftpd, syslog, I think we should also have sshd :P Has anyone tried to use 8x synth_dexed on Linux? I think it could be interesting with PREEMPT_RT. |
|
I don't think synth_dexed has been ported to Linux. Might be a fun experiment for someone, though. If it is done in a way that keeps dependencies minimal (e.g., only ALSA, no jackd) it might run on a very stripped down "embedded Linux" type system containing not much more than the kernel, but allow for easier implementation of things like USB gadget mode as a sound device, MIDI device, and at the same time USB host for MIDI controllers, mass storage, etc. (I think) and networking, including ssh. Let me know if you ever start experiments in that direction. But that'd be a completely new development unrelated to today's MiniDexed. When I started MiniDexed I wanted something small and efficient, and not gigabytes of software with thousands of files. |
|
Build for testing: |
|
So far I have tested this successfully on RPi Zero 2 W. We should also test it on the other models:
@soyersoyer which models do you have access to? At least we should ensure that it won't crash on any model. |
|
I've a 3b+ and 4 for MiniDexed. I'll check out this PR on those. |
Not synth_dexed but 3x VDX7 is achievable on RPi 3A+, this is due to VDX7 being bit accurate emulation, also author made possible to run it in headless setup. |
|
Hello, thanks a lot for this update. |
|
Build for testing: |
|
Hello, thanks a lot for this update. |
|
Hi All, Thanks for working on this enhancement. However, I too am stuck on the splash screen with Minidexed_2024-12-19-ccec4b6 on a Raspberry Pi 3 A+ wifi. I will try the previous version to see if that works. Update: Previous version MiniDexed_2024-11-19-5aad2ef also stuck at the splash screen. Not sure if it is me or the build? |
|
Does anyone have a version after MiniDexed_2024-11-16-bfca612 working? #747 (comment) |
|
Hello, thanks for the MiniDexed_2024-11-16-bfca612 build, but unfortunately, it stuck also as MiniDexed_2024-11-19-5aad2ef on the splash screen (showing build number). I plugged an hdmi display (and edited the .ini for debug) but nothing is displayed. |
Yes, I have the latest one running, albeit with some issues:
So what needs to be changed? (Better ideas welcome!)
|
|
Build for testing: |
|
Please see and test #783 |
Hello!,
I know this is somekind "workaround" but hey! everything works just fine. Tested with (rtpMIDI+Hatari+Twenty-Four 3.0 by Steinberg). Br. |
|
Hi All, Just confirming that I followed Marko's procedure and that I got it working too with a RPi 3A+ wifi. Loaded Filezilla on Linux and FTP works to the SD card. Enzo |
Continuation from #744
This adds wired and wireless network for supported models:
Closes #43
Thanks @omersiar
This allows us to send MIDI e.g., from DAWs, Dexed on the PC, or even sysex for voices from sites like patches.fm
Documentation:
https://github.com/probonopd/MiniDexed/wiki/Networking#ethernet-and-wlan-support