Reply 760 of 965, by HunterZ
- Rank
- l33t++
Thanks. How do I set that QT5 option? I'm not too familiar with cmake.
Thanks. How do I set that QT5 option? I'm not too familiar with cmake.
wrote:Thanks. How do I set that QT5 option? I'm not too familiar with cmake.
There are a number of ways 😀
If you use ccmake or cmake-gui, it will appear very easy. You can also type
cmake -D mt32emu-qt_WITH_QT5:BOOL=ON <path_to_sources>
on command line. Alternatively, you can lookup the property inside the CMakeCache.txt file and edit.
Just got the latest commit from the git repo, and compiling the emulator libraries (mt32emu) works fine, but compiling anything else that depends on the libraries (like mt32emu_qt) ends up spewing those kinds of errors:
Master.cpp:(.text+0x25a7): undefined reference to `MT32Emu::FileStream::FileStream()'
Master.cpp:(.text+0x2614): undefined reference to `MT32Emu::FileStream::open(char const*)'
Master.cpp:(.text+0x264a): undefined reference to `MT32Emu::ROMImage::makeROMImage(MT32Emu::File*)'
Master.cpp:(.text+0x266b): undefined reference to `MT32Emu::ROMImage::getROMInfo() const'
Master.cpp:(.text+0x26cb): undefined reference to `MT32Emu::FileStream::FileStream()'
Master.cpp:(.text+0x2738): undefined reference to `MT32Emu::FileStream::open(char const*)'
Master.cpp:(.text+0x2772): undefined reference to `MT32Emu::ROMImage::makeROMImage(MT32Emu::File*)'
Master.cpp:(.text+0x2793): undefined reference to `MT32Emu::ROMImage::getROMInfo() const'
CMakeFiles/mt32emu-qt.dir/src/Master.cpp.o: In function `Master::freeROMImages(MT32Emu::ROMImage const*&, MT32Emu::ROMImage const*&)':
Master.cpp:(.text+0x2aeb): undefined reference to `MT32Emu::ROMImage::getFile() const'
Master.cpp:(.text+0x2b11): undefined reference to `MT32Emu::ROMImage::freeROMImage(MT32Emu::ROMImage const*)'
Master.cpp:(.text+0x2b4b): undefined reference to `MT32Emu::ROMImage::getFile() const'
Master.cpp:(.text+0x2b71): undefined reference to `MT32Emu::ROMImage::freeROMImage(MT32Emu::ROMImage const*)'
I'll attach the full logs of the compilation attempts and CMake.
Is this a known issue, sergm, or did I mess something up?
Also, when I did a 'make install' (with root privileges of course) after compiling the libraries, not all the include files were transferred, so I had to copy them to /usr/local/mt32emu/ manually.
That's not an issue. The library interface is in active development. When you compile the library stand-alone, it provides new API that the other components cannot use. There are corresponding compile options if you want to play with. I have some more thoughts about that and hopefully things will stabilize in a couple of weeks.
What's the status of optimizing in the library, in general and in particular on ARM devices? If you've already mapped out some objectives, i would like to try to help.
All hail the Great Capacitor Brand Finder
Sergm: with the current qt-UI code it seems that changes in the properties are not saved on OS X.
I hit properties, set something, hit save, open again and almost all changes will be reverted (the "reverb enabled" drop down seems to stick). Is this intentional or is it a bug. Tsoliman on #munt is having the same issue (or actually he mentioned it and I confirmed).
Donimus: No, I'm not aware of this behaviour. There is nothing like that I can see on Win/Linux/FreeBSD. Probably a Qt bug. Do you use Qt5? I sometimes observe very unpleasant things in Qt5 while it's in development...
gdjacobs: Nothing changed in that area. The general code style (at least within the library) is ANSI C compatibility, so I hope there is (almost) nothing to do to port it to the ARM arch. As for the speed, I expect today's mobiles are fast enough 😀
Donimus: Similar things might happen if you stop the synth and then try to change some settings. This is because the settings are stored in the synth's vars and then reloaded. If the synth is closed, some settings take no effect.
Yes, I've stopped the synth, changed stuff and then started it again. Seemed like the logical thing to me 😉
And yes, QT5.5(.1I think).
OK, I'll commit a workaround for you personally 😀
wrote:gdjacobs: Nothing changed in that area. The general code style (at least within the library) is ANSI C compatibility, so I hope there is (almost) nothing to do to port it to the ARM arch. As for the speed, I expect today's mobiles are fast enough 😀
It's fine as far as portability. My motivation is to achieve real time emulation on a platform like the Pi2. At present, a 1ghz Cortex A7 core can almost handle it, but not quite.
My sense is that most Munt development has been oriented to accuracy at present depending on general good coding practices to keep performance requirements in check. Do you have any thoughts on more radical optimizations which could be applied?
All hail the Great Capacitor Brand Finder
When thinking about performance improvements, I guess, the best hopes should be set on using SSE-like intrinsics. However, we might not achieve a significant performance boost. The most CPU-demanding part is the sample generator in LA32WaveGenerator that emulates the LA32 chip. By the logic, the model heavily relies on the LUTs found within the chip, so the processing is quite problematic to do in parallel by a single processor core. The higher-level version of the emulation engine in LA32FloatWaveGenerator is much easier to speed up but it also significantly slower due to the use of floating-point computations (including sines and exponents).
Also, radical optimizations often end up with code harder to read, debug and maintain, which we'd like to avoid and keep the code as clear as possible. If there was a break-through optimization in the critical path, I think it would be worth to increase the code complexity. But instead, many of optimizations are compiler and/or platform specific, and therefore are not much desired.
wrote:When thinking about performance improvements, I guess, the best hopes should be set on using SSE-like intrinsics. However, we might not achieve a significant performance boost. The most CPU-demanding part is the sample generator in LA32WaveGenerator that emulates the LA32 chip. By the logic, the model heavily relies on the LUTs found within the chip, so the processing is quite problematic to do in parallel by a single processor core. The higher-level version of the emulation engine in LA32FloatWaveGenerator is much easier to speed up but it also significantly slower due to the use of floating-point computations (including sines and exponents).
Also, radical optimizations often end up with code harder to read, debug and maintain, which we'd like to avoid and keep the code as clear as possible. If there was a break-through optimization in the critical path, I think it would be worth to increase the code complexity. But instead, many of optimizations are compiler and/or platform specific, and therefore are not much desired.
Perfectly understandable. I wouldn't want a C preprocessor soup either.
I'll see how much time I've got, but I'd like to begin reading and familiarize myself with the code. You mind if I begin asking questions when the confusion sets in?
All hail the Great Capacitor Brand Finder
No, I don't mind. But, be sure to create a topic for that, please 😀
Hand-written SSE should always be the last resort. Making sure data in hot loops always fits in the 64 byte CPU cache line and reducing data dependencies (so that the CPU core can auto-paralellize the code) is the most maintenance-friendly way of optimization.
Also, SSE code is the best way to prevent contributions since very few people understand this stuff 😜
Of course. I'd add that relying entirely on the optimization performed by the compiler is even more maintenance-friendly way, and that's what we practice 😉
Unfortunately, the algorithm in LA32WaveGenerator is already not quite easy to understand in contrast to the one in LA32FloatWaveGenerator. So, if a super-optimized version ever appears, it'll most probably be in a separate module.
Are you interested in patches for improving ABI compatibility in the C++ interface? I know it's more difficult to do in C++ compared to C, but I was thinking of introducing a d-pointer (aka "Pimpl idiom") and remove all private members from the headers. The exported classes would then only have public and protected members and thus any changes in the private members would not break the ABI.
Obviously doing this will break the current ABI, but that already happened now with the latest commit (making isActive() non-const).
Yep, the ABI was changed in that commit, but it had been also changed before that (so, I'm bumping the major version).
I think about a bit different approach for retaining C++ ABI compatibility further on. Moreover, I assume C++ API must fully correspond to the C and plugin ones. I'll add a facade class for that shortly (well, I should actually start from this point but I'll survive 😀 ).
Well, I don't know if I should slap myself on the back or in the face. The Broadcom CPU on the RPi 2 can successfully run Munt in real time, no dropped samples.
Re: Roland MT-32, CM-32L + General MIDI for $50" Building a MIDI box
CXXFLAGS used, as recommended by ARM:
-Ofast -mcpu=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard
All hail the Great Capacitor Brand Finder
While working on ARM builds, mt32d and xmt32 were both found to segfault for recent git commits. I've performed a bisection analysis and believe I've located the problematic commit, but I would appreciate confirmation.
Here's the output:
961ec3ce7d06974e10e3c786d505c21fb43f35c4 is the first bad commit
commit 961ec3ce7d06974e10e3c786d505c21fb43f35c4
Author: sergm <sergm@bigmir.net>
Date: Sun Mar 6 19:42:05 2016 +0200
- Public methods of Synth made protected from calling when the synth is closed
:040000 040000 521339dbc99a20d7577d9e5f35c2f03de2b69777 24095332e6319df14428fcc65ee44e4aa6218e52 M mt32emu
Edit: I've confirmed that using the tree at the previous commit, 9939950, builds a fully functional mt32d. Using GDB determined the area of the segfault to be on the first call of getMT32Settings. My take is that the member variable opened is causing the segfault when the reverb constructor is called.
One mystery, though. I have no idea why it's doing it with mt32d and xmt32 and not mt32emu-qt.
Update: Apr. 4, 2016
Fault fixed in the latest git tree. Thanks, sergm!
All hail the Great Capacitor Brand Finder