VOGONS


Reply 20 of 36, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

Thanks, Dominus!

Yes, NewRisingSun, this is very possible. We did not implement anything in that field and upon a change of any reverb parameter it is immediately applied. If the reverb mode changes, reverb model is swapped, so the reverb tail is immediately cut off.

I planned to dive into the control ROM to define how it should actually work (clearly, it is impossible to implement such a thing with the real reverb chip, only by setting the reverb time and level to 0 and waiting for the RAM to get cleared). But that comes 3rd in my priority list (FYI, those are: API improvement, emulation of old MT-32 quirks, reverb change ramping, pitch variations depending on MCU load).

Reply 21 of 36, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

Actually, not. Reverb is innocent. Instead, the reverb keeps the shot after sound but the timbre itself got killed by the reset sysex that goes some time after (when "Origin Sound System" is displayed). Weird, maybe it's a sysex transfer speed issue...

Reply 22 of 36, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

I see, that's why everything is ok, except for the last sfx.
I would offer to test some stuff but I'm not sure I can stand to watch the intro another time...(after the fifty times I watched it now...

But seriously if you want me to mess with any of the delay things in the munt gui settings, I can do some more runs 😉

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for OS X (10.4-10.14 ppc/intel 32/64bit) codesigned for gatekeeper
DOSBox SVN with SDL2 snapshot for OS X (10.7-10.14 intel 64bit) codesigned for gatekeeper

Reply 24 of 36, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

Well, the capture sounds pretty similar on my CM-64 (even the click is there when the reset is handled). I think, that's because the MIDI capture contains the delay between the noteOn and the reset as it was played with munt, i.e. there were no MIDI transfer delay. So, Dominus, it would be great if you checked it playing on the MT-32. Not sure whether you have a MIDI player on your system but DOSBox + gsplay should definitely do the job.

Reply 25 of 36, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

so through dosbox+mt32 playback the midi with gsplay?
Got to try playing it also on my CM64 (got both an MT32andva CM64)...

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for OS X (10.4-10.14 ppc/intel 32/64bit) codesigned for gatekeeper
DOSBox SVN with SDL2 snapshot for OS X (10.7-10.14 intel 64bit) codesigned for gatekeeper

Reply 27 of 36, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

OK, as I understand, the actual problem is that munt not only terminates any playing notes upon reset (which an actual unit also does) but also disables reverb for a short time (until the next MIDI message arrives). This is actually a bug because it was assumed that the reverb buffers are empty after the reset for some reason... I'll fix.

Reply 28 of 36, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

Do you actually need me to check anything after coming to this conclusion?

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for OS X (10.4-10.14 ppc/intel 32/64bit) codesigned for gatekeeper
DOSBox SVN with SDL2 snapshot for OS X (10.7-10.14 intel 64bit) codesigned for gatekeeper

Reply 30 of 36, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

OK, Dominus, you can find the updated app here.

It should render the reverb tail smoothly across the synth reset. It may also help to delay all the MIDI events in the synth properties panel, so that the reset might occur even after the patch actually finished.

Also, the new build is statically linked with Qt, so please let me now if it behaves strangely.

Reply 31 of 36, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

ok, will test tomorrow (or maybe if the kids keep on sleeping, right now).

(do you have a build script/instructions handy to build it statically? I *do* have it building dynamically against MacPort's qt5 package but I'd like to know more how to handle qt static)

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for OS X (10.4-10.14 ppc/intel 32/64bit) codesigned for gatekeeper
DOSBox SVN with SDL2 snapshot for OS X (10.7-10.14 intel 64bit) codesigned for gatekeeper

Reply 32 of 36, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

With Qt5 it's going to be a pain. I did build it in Window with a dozens of hacks. Cmake is unable currently to add all the necessary dependencies to the build. Moreover, there is also an additional dependency on platform plugins which require a direct reference in the sources. So, most simply do not build Qt5 statically.

However, Qt4 static build is way simpler. You just add a couple of frameworks to the CMAKE_EXE_LINKER_FLAGS_RELEASE (or elsewhere) like "-framework Cocoa -framework Security", etc. More things are needed for PortAudio but I assume you may simply omit this dependency along with QtMultimedia. Btw, ensure GIF support is included while building Qt, as static builds do not support plugin loading (the images we use are in this format).

Reply 33 of 36, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

Thanks - sounds like something I can manage.

So, that bug is squished. Just recorded it again and it is now smooth without changing any settings.

One other thing, though: Any chance of adding an option to use both "AudioFileWriter" *AND* a real output device? So you can listen and record.

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for OS X (10.4-10.14 ppc/intel 32/64bit) codesigned for gatekeeper
DOSBox SVN with SDL2 snapshot for OS X (10.7-10.14 intel 64bit) codesigned for gatekeeper

Reply 34 of 36, by sergm

User metadata
Rank Oldbie
Rank
Oldbie
Dominus wrote:

So, that bug is squished. Just recorded it again and it is now smooth without changing any settings.

Cool, good to know.

One other thing, though: Any chance of adding an option to use both "AudioFileWriter" *AND* a real output device? So you can listen and record.

Yeah, that's really bad. I actually never used that for recording audio, just as an audio driver with perfect sample rate. For now, the only option is to capture MIDI and to convert it to the wave audio afterwards. Not the same because you can easily miss some SysEx as you know 😀

The problem is if I add a real audio sink, the sample rate of audio recorder immediately stops being perfect. Perhaps, I'll just add a recording option to other audio drivers (which seems to be logical).

Reply 35 of 36, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

Slightly off-topic, but still:

Dominus wrote on 2016-02-06, 20:56:

(do you have a build script/instructions handy to build it statically? I *do* have it building dynamically against MacPort's qt5 package but I'd like to know more how to handle qt static)

sergm wrote on 2016-02-06, 21:06:

With Qt5 it's going to be a pain. I did build it in Window with a dozens of hacks. Cmake is unable currently to add all the necessary dependencies to the build. Moreover, there is also an additional dependency on platform plugins which require a direct reference in the sources. So, most simply do not build Qt5 statically.

Good news, with Qt 5.14 making a static build is likely no longer a pain. All transitive dependencies are now included automagically. I hope this helps with builds for iOS too. See [QTBUG-38913][QTBUG-76562] for more info, if interested 😀

Reply 36 of 36, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

Thanks. I'll test that out once I have a chance

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for OS X (10.4-10.14 ppc/intel 32/64bit) codesigned for gatekeeper
DOSBox SVN with SDL2 snapshot for OS X (10.7-10.14 intel 64bit) codesigned for gatekeeper