i'll send it back for sure!

8bitbubsy wrote on 2020-10-06, 20:14:

Yeah, MPU401 support would be cool! Also traffkin, please be sure to send the code back to me if you manage to complete these implementations/fixes, so that I can continue with bugfixing in the future. I'm sure that there are more of the old bugs in there.

traffkin wrote on 2020-10-01, 14:23:

working on this, trying to put filters into parallel buffer prior to mixing channels, not an easy task at all... some midi functionality will be added too

if you need hardware for testing/adding support just tell me

Thanks for this, really amazing, brings back so many memories from the second half of the good ol' nineties.
Just gave it a test run, through DOSBox actually, since I don't have any "true" machine.
Once I get my hands on a functioning SB16 PCI card I will run FreeDOS of course! 😀

Thanks, I'm glad you like it. There's also my accurate FT2 clone for Window/macOS/Linux in case you want to make your life a bit easier: https://16-bits.org/ft2.php

8bitbubsy wrote on 2020-12-10, 10:14:

Thanks, I'm glad you like it. There's also my accurate FT2 clone for Window/macOS/Linux in case you want to make your life a bit easier: https://16-bits.org/ft2.php

Hi,
Would you consider making statically linked versions of the Windows executables? The dependency on VS 2015 runtime and the universal crt which are rather picky concerning installation on older systems ( not to mention the over complicated way of app local using of the runtime compared to earlier VS versions) makes it hard for me to use your newer versions as portable ones. Your earlier beta versions were much better in this respect.
Thanks in advance.

Falcosoft wrote on 2020-12-11, 00:12:

Would you consider making statically linked versions of the Windows executables? The dependency on VS 2015 runtime and the universal crt which are rather picky concerning installation on older systems

Is that even possible...? The reason why I hate using Visual Studio is because of that arbitrary dependency on the VS runtime rather than just sticking with plain old "msvcrt.dll"...

Does Microsoft actually have a option somewhere to statically link the Visual Studio library?

Huh, the options to embed the MSVC runtime always existed.

DracoNihil wrote on 2020-12-11, 07:49:

Falcosoft wrote on 2020-12-11, 00:12:

Would you consider making statically linked versions of the Windows executables? The dependency on VS 2015 runtime and the universal crt which are rather picky concerning installation on older systems

Is that even possible...? The reason why I hate using Visual Studio is because of that arbitrary dependency on the VS runtime rather than just sticking with plain old "msvcrt.dll"...

Does Microsoft actually have a option somewhere to statically link the Visual Studio library?

Yes, it has and it always has had the option. The problem with the new refactored dynamic runtime of VS 2015 is:
1. It has a tendency of failing to install (mostly on Win 7) with error code 0x80240017 Unspecified error:
https://answers.microsoft.com/en-us/windows/f … ae-4d4847937ccc
https://techcult.com/wiki/fix-microsoft-visua … ror-0x80240017/
And troubleshooting this error is not straightforward to say the least.
It's mainly because Universal CRT is a system component on some Windows versions but not on others. If you ask me with this refactoring the situation is worsened compared to earlier versions
contrary to the intention to make things simpler and better:
https://devblogs.microsoft.com/cppblog/introd … -universal-crt/

2. At first app local deployment of VS 2015 runtime was not even supported at all but later (mainly because of pressure from developers) they added it but the implementation is way worse than before. To support all possible systems you need more than 40(!) different dlls compared to the 2-3 in previous versions.
https://stackoverflow.com/questions/32601941/ … ocal-deployment

Falcosoft wrote on 2020-12-11, 00:12:

Hi, Would you consider making statically linked versions of the Windows executables? The dependency on VS 2015 runtime and the […]
Show full quote

8bitbubsy wrote on 2020-12-10, 10:14:

Thanks, I'm glad you like it. There's also my accurate FT2 clone for Window/macOS/Linux in case you want to make your life a bit easier: https://16-bits.org/ft2.php

Hi,
Would you consider making statically linked versions of the Windows executables? The dependency on VS 2015 runtime and the universal crt which are rather picky concerning installation on older systems ( not to mention the over complicated way of app local using of the runtime compared to earlier VS versions) makes it hard for me to use your newer versions as portable ones. Your earlier beta versions were much better in this respect.
Thanks in advance.

The reason I removed the statically linked runtime is because when linked, the .exe would trigger 15-20 false virus positives on virustotal (yes, really). People would complain about it all the time, and I don't want less people to use my projects because of false virus positives.
Btw, the runtime installer (which is linked in readme_now.txt in the release zip) installs fine on Windows XP, so I don't see the problem.

8bitbubsy wrote on 2020-12-11, 11:12:

Falcosoft wrote on 2020-12-11, 00:12:

Hi, Would you consider making statically linked versions of the Windows executables? The dependency on VS 2015 runtime and the […]
Show full quote

8bitbubsy wrote on 2020-12-10, 10:14:

Thanks, I'm glad you like it. There's also my accurate FT2 clone for Window/macOS/Linux in case you want to make your life a bit easier: https://16-bits.org/ft2.php

Hi,
Would you consider making statically linked versions of the Windows executables? The dependency on VS 2015 runtime and the universal crt which are rather picky concerning installation on older systems ( not to mention the over complicated way of app local using of the runtime compared to earlier VS versions) makes it hard for me to use your newer versions as portable ones. Your earlier beta versions were much better in this respect.
Thanks in advance.

The reason I removed the statically linked runtime is because when linked, the .exe would trigger 15-20 false virus positives on virustotal (yes, really). People would complain about it all the time, and I don't want less people to use my projects because of false virus positives.
Btw, the runtime installer (which is linked in readme_now.txt in the release zip) installs fine on Windows XP, so I don't see the problem.

Hi, the problem is not with XP but mainly with Win7 systems. I personally met some where the installation failed with the above detailed error. Not to mention using your FT2 on systems where you do not have permission to install system components...
Maybe as a compromise you can make a separate downloadable package with the app local distributable dlls that one can copy next to your executable (even if there are many of them).

Creating 32-bit/64-bit runtime zips with the DLLs needed seems feasible, I'll look into it one day.

Hi!
Any news in the front of the "original" dos version? Have a nice day!

I'm not really working on it anymore (FT2.11 is the last version), but traffkin is trying to add MPU-401 MIDI support and also improve the LPT DAC support.

8bitbubsy wrote on 2020-12-22, 19:00:

I'm not really working on it anymore (FT2.11 is the last version), but traffkin is trying to add MPU-401 MIDI support and also improve the LPT DAC support.

Ah! Ok! Thank you!

Falcosoft wrote on 2020-12-11, 11:20:

Hi, the problem is not with XP but mainly with Win7 systems. I personally met some where the installation failed with the above detailed error. Not to mention using your FT2 on systems where you do not have permission to install system components...
Maybe as a compromise you can make a separate downloadable package with the app local distributable dlls that one can copy next to your executable (even if there are many of them).

With the latest version of the PT2/FT2 clone that I released today, I updated the "readme now.txt" file (inside the release zips) with an URL to a zip that contains the needed x86/x64 DLLs to run it without the runtime installed.
I made a fresh install of Windows 7 Ultimate x64 on a laptop and tested it, and it works there. However, it may fail on XP, Vista and Windows 8...

traffkin wrote on 2020-09-12, 16:34:

thank you!!! i'll look into it tomorrow and start to analyze possibilities. and of course will keep you updated!

8bitbubsy wrote on 2020-09-12, 10:33:

I sent you the source code and a readme.txt file to explain how to use it.

Any progress with MPU401 support?

LABS wrote on 2021-06-02, 17:08:

traffkin wrote on 2020-09-12, 16:34:

thank you!!! i'll look into it tomorrow and start to analyze possibilities. and of course will keep you updated!

8bitbubsy wrote on 2020-09-12, 10:33:

I sent you the source code and a readme.txt file to explain how to use it.

Any progress with MPU401 support?

I would like it!

I haven't heard from traffkin in a long time, I assume he either doesn't have time, or gave up on it... I think he had other plans than just MPU401 support too, which could've made it more difficult to achieve what he wanted.

8bitbubsy wrote on 2021-07-10, 20:00:

I haven't heard from traffkin in a long time, I assume he either doesn't have time, or gave up on it... I think he had other plans than just MPU401 support too, which could've made it more difficult to achieve what he wanted.

Still no word from him?

I really wish I knew the low-level ASM coding stuff you mentioned in this thread in a previous post/reply. MPU401 is a "software"/ firmware MIDI synthesizer chip built onto a lot of soundcards 'from the day', correct? I seem to remember him saying something about external devices...I guess I don't understand what he was trying to do or get working. But I have definitely used FT2.08 with two or more (i think the cabling I had permitted 3) external midi devices, was able to sequence them simultanously, too. This required daisy-chain midi cable hookups thru a 'midi-thru' port that two of the devices graciously had. And I too experienced a 'F load' of frustration related to that 'send midi program change' stuff. So I too have downloaded that special version you made for him.

Thanks a LOT for your development efforts with this, but more-so on your SDL FT2 Clone. That thing is the only reason I'm able to make music with the focus on music and not on something like "oh well first i need to finally get dos network driver stack working and netlogon bullsh!t working and UNC (\\host\share) network drive mounting working" that somehow ends up in hardware failure due to too many removals of harddisk drive or something (on the last real DOS 6.xx machine I had setup). I still think I'll end up setting a dos6.xx machine up again due to lack of midi out support in the clone, as that's something I actually was starting to use heavily.

I've talked to you on IRC before and pestered you quite a bit about the midi implementation stuff, and the feeling I get is that it ain't gonna happen. So I'll spare those requests for now:)

Dave

jxalex wrote on 2018-11-07, 16:14:

Hello, it seems like dream. IF there will be a new software then why not the new hardware devices too? Look here we are also cr […]
Show full quote

Hello, it seems like dream. IF there will be a new software then why not the new hardware devices too? Look here we are also creating new soundcards.
Is it difficult to get 2 cards at the same time to work (multitrack output!) ? In a work of double GUS?

Or what about the new multitrack card?
After I get the card ready then I can fully provide specifications so it can as well be 3x stereo output, with one IRQ in use, which can be used as routing for different external effect units.
Also there is not so much technical difficulty to add 2 MIDI ports on the new card, as then the data sending will be with 16bit port instead of 8bit port, while status register will be the same.

Yeah having unmixed / multi track output would be pretty slick. I've even tried 'hacking' two "track" output with L/R balance panning. (yeah laugh it up.. it was a LONG time ago, i was young) and a multitrack mixer... Worked sorta, but the sound card that I was using had a *lot* of bleeding between channels... so it didn't work too well... I think I tried it again recently, with ladspa or alsa configuration (with FT2-clone) and it worked, but then realized what a pain in the ass that was to gain two track mixable output and lose stereo output... 🤣

But hear me out on this one. The ultimate dream would be FT2-clone's playback (speed/pitch, direction if speed was in the negatives) being controlled by XWAX. If you guys don't know what it is, check it out. (http://xwax.org/) I trusted my instinct and purchased two Serato (commercial "digiital DJ " software) vinyl records, as it said it worked best with them, and low and behold, it works awesome. It plays MP3s and WAVs relative to the speed / direction of the vinyl record, with impressively low latency . Like as in it feels like I am playing actual vinyl. I've used many of the commercially available hard/software packages available (even the actual Serato program) and I can hear, and feel, a "delay" or latency. You can't cut & scratch with that going on. But I definitely have been able to with xwax. So, FT2 is pretty low latency, like no latency (for example muting / muting channels / groups of channels), so I think that in theory it would be acheivable.

Neither XWAX or FT2 support external things ( XWAX doesn't output the timecode vinyl signal, and FT2-Clone doesn't support input or "midi sync" etc so there'd be no infrastructure for it).. That's why I am calling this a dream.

Both are opensource... So who knows...
Just wanted to share with ya'll cuz I saw mention of ft2-related dreams =)