munt 1.2.0 installer makes uninstall highlighted in start menu.
Also if you uninstall, install, reboot, the driver will not be installed.
some discussion about quality
http://queststudios.com/smf/index.php/topic,2873.20.html
also the tfx file from that link doesn't show instrument names in theplayer (only empty squares)
wrote:munt 1.2.0 installer makes uninstall highlighted in start menu.
Also if you uninstall, install, reboot, the driver will not be installed.
Ah, yeah. The driver gets deleted by the system after the reboot. 😒
Well, I think there is no need to uninstall Munt anymore 😉 it should be finely installed to the same directory when upgrading.
some discussion about quality
http://queststudios.com/smf/index.php/topic,2873.20.html
Thanks, will look at it.
also the tfx file from that link doesn't show instrument names in theplayer (only empty squares)
Yep, I also noticed 0 chars in some other custom instruments... weird. I think I just need to replace all the unprintable characters with spaces.
the strange thing is that my mt-32 displays instrment names when playing tfx.mid
though i think they are just the default ones (not reprogrammed ones)
other strange thing is that for example colonel's bequest full track at the beginning has for example SawSweep0 in munt while it is SawSweep3 on my mt32.
Ok, it looks mt-32 doesn't show it properly. It just takes letters from previous track so for example i have winde 1 instead of wind cause of flute 1 being in track before.
So I guess the tfx instruments are being shown simmilar not proper way.
So maybe just leave the squares as they are as i guess they always give some extra info.
The squares are also a sign for the track to be designed for cm-32l 😀 Nice feature of munt 😀
Gee! How many bugs Roland's control ROMs contain, unbelievable.
Actually, I'm getting tired of our attempts to reproduce multiple Roland's bugs. Besides, there're things _impossible_ to be accurately reproduced using the current pretty high level model like the following.
From what I got researched, it seems the implementation of TVP in real devices just sucks. As we know, pitch is controlled by the MCU solely and it looks like MCU not always capable to accurately perform the pitch envelope. Those weird Violin 1 attacks ( Munt Reloaded - Development ) could well be caused by slow MCU. Similar thing happens with Syn Mallet in Cryo’s Dune.
So, if we’re going to hunt for 100% accuracy, we should have accurate emulation of the MCU and its timing. Needless to say, this makes all the bugs 100% accurately reproduced.
In fact, version 1.2.0 is the first step towards the integration with MESS. The main goal is to polish up the new log-based _modularized_ wave generator.
Though, this way Munt could appear slow again. But we’ll see...
It's weird not seeing the MIDI activity light next to the simulated LCD display in the QT GUI. I always look at it on my real MT-32 when SysEx is being transferred, "just to be sure" 😀
Err, unfortunately, I have no idea even whether the LCD is emulated virtually correct. But I strongly suspect it wasn't right in the previous version (i.e. in the .Net display application). Well, it seems easy to add the light but it'll behave as in my CM-64 😜 (again, no idea whether this behaviour is similar to the MT-32's).
Eek. My CM-64 turns the LED on while it either processes a sysex or there is at least one active partial. 😒 Looks like we need to start "MESSy Munt" ASAP...
wrote:On my MT-32 it's just a green LED that flickers when the MT-32 receives MIDI data.
wrote:Eek. My CM-64 turns the LED on while it either processes a sysex or there is at least one active partial. 😒 Looks like we need to start "MESSy Munt" ASAP...
I think none of you is completely right. The truth is MT-32 and CM-32L LED makes a blink when it receives a message. The length of each blink always takes the same amount of time. But the faster the next message arrives the the faster the LED blinks again, so it blinks more frequently. At some point the gaps between blinks are not visible at all hence the led is turned on constantly. During playing the song the led is constantly on. During receiving sysex it depends on the length of each sysex and also the time gap between them.
led blinking
http://www.youtube.com/watch?v=lnEGBovHbMc
whenever a new instrument starts playing lcd displays:
track|sound group|sound
when it is a new sound the "sound group" is called "memory"
http://www.youtube.com/watch?v=UJBmrEPaIAs
Hmm, this is also not completely true 😀
When you press a key and hold it (or hold the sustain pedal) selecting non-sustaining instruments like piano, celesta or vibes, the LED turns off right when all the partials go away. But when you depress the key (or the pedal) the LED turns off immediately.
TFX: those guys are nit-picking. They should compare with the output of Munt v0.1.3 🤣
Sadly because of what it is, the output from Munt will always be nit picked. I suspect you're probably more critical of it yourself [& those who contribute to the R&D].
I was wondering as munt is already in a nice state (cm-32l part) and it doesn't look mt-32 part will be added soon. Could you consider adding the mt-32 bug i write about here:
http://queststudios.com/smf/index.php/topic,2138.40.html
I mean the volume for phaser and distorted guitar so that they are heard like on a mt-32. Not the other bug that sometimes makes it too loud/silent. That would make all dune 2 music sound ok with munt. And I think this is the most important mt-32 bug as it affects lots of songs in dune 2. I think other mt-32 bugs are just affecting single sounds or some slight sound differences hence not that important.
Hmm, well. From what I've learned for the last two years, the LA32 chip used in MT-32 and later compatibles has no major modifications. Which means all those quirks must be finely reproduced if we make a fair emulation of the control ROM. Thus, analyzing and reproducing the software bugs may appear just a waste of time.
So, as I said above, the current plan is to go towards MESS. Even if it appears a wrong way, it'll anyway open for us great possibilities to analyze LA32 input / output in almost real time, i.e. there will be no need to dive deep in the code of each of the control ROM versions.
Besides, those guys hanging around on #munt channel @ FreeNode (actually they greatly helped me with the LA32 internals) are targeted not exactly at the MT-32 emulation. 😀
Actually, I've already made an attempt to emulate the pitch envelope overflow of the old MT-32. There is an #ifndef MT32EMU_QUIRK_PITCH_ENVELOPE_OVERFLOW_MT32 in TVP.cpp which tries to make the "Lightning" patch to sound right. Not sure, but it might solve the problem with the Dune 2 guitar as well. Will check.
EDIT: nope.
sergm: Thanks for being open-minded and responsive to feedback. If people nitpick munt's inaccuracies or bug you for features, it's only because we're so excited about it and want to see it attain its full potential 😀
The improvement in the latest Munt builds is tremendous. I for one want to congratulate you sergm and anyone else who has been working on Munt.
Thank you so much for your work! 😀
wrote:The improvement in the latest Munt builds is tremendous. I for one want to congratulate you sergm and anyone else who has been working on Munt.
Thank you so much for your work! 😀
I second that! It's impressive work for sure.
