| |
chatGPZ
Registered: Dec 2001
Posts: 11114 |
Release id #164858 : VICE 3.2
So, finally, we pushed it out. The GTK3 port isn't 100% done yet, but usable enough for testing it. It has a couple known issues and open ends - which are listed here: http://vice-emu.pokefinder.org/index.php/Todo#GTK3_UI - grab experimental binaries here: https://sourceforge.net/projects/vice-emu/files/experimental%20..
Due to the massive amount of features, we need help with testing the damn thing, especially on platforms other than linux.
It would also be great if those who offered to set up nightly builds for OSX would step up and do it :) |
|
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Awesome guys! Still hunting for the Mac-slowdown and fixing automated builds. |
| |
DKT
Registered: Aug 2004
Posts: 96 |
Testing on Win10x86...
Vice crashes when I try to go to ROM settings. |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
Same here on a Win7 VM. Please open a ticket at https://sourceforge.net/p/vice-emu/bugs/ so we can have look at why this happens.
Of course hooking up a debugger and posting the backtrace would be very helpful. |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
Quoting CompyxSame here on a Win7 VM. Please open a ticket at https://sourceforge.net/p/vice-emu/bugs/ so we can have look at why this happens.
Of course hooking up a debugger and posting the backtrace would be very helpful.
Never mind, some idiot (me) forgot to properly terminate a list of drive expansion ROMS, leading to a segfault. Fixed in trunk.
Thanks for reporting, one less bug :) |
| |
Perplex
Registered: Feb 2009
Posts: 254 |
Great work!
One small "issue" (SDL1 build on Linux): when switching to Debug border mode, the window changes size from 719x544 to 823x544. It would be preferrable that the window size be expanded in both dimensions so as to keep the same smooth scaling factor used in normal border mode. In older VICE versions the window did not change size at all, so it is kind of an improvement, just wondering why it's just partially expanded? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11114 |
the main reason is likely: noone tests with SDL1 on linuks :) |
| |
Jammer
Registered: Nov 2002
Posts: 1289 |
Why do 8580 low basses fart that much without digiboost? Unless I don't play $d418 samples, I use 8580+digiboost setting - otherwise it's painful to listen to anything with lows :( I don't understand what happens to sound emulation with each new release - it plainly sucks and has nothing to do with real SID distortion. Sorry, guys - I rarely switch into Ian Coog's school of critique but this is quite frustrating :D |
| |
chatGPZ
Registered: Dec 2001
Posts: 11114 |
have you reported a bug with a testcase? |
| |
Linus
Registered: Jun 2004
Posts: 638 |
Quote: Why do 8580 low basses fart that much without digiboost? Unless I don't play $d418 samples, I use 8580+digiboost setting - otherwise it's painful to listen to anything with lows :( I don't understand what happens to sound emulation with each new release - it plainly sucks and has nothing to do with real SID distortion. Sorry, guys - I rarely switch into Ian Coog's school of critique but this is quite frustrating :D
This. It's ridiculously broken. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11114 |
did you report a bug with a testcase?
the one ridiculous thing with those reSID bugs is... that a bunch of people prefer whining (a lot) over doing anything that might help to fix them. guess what will happen. |
| |
Jammer
Registered: Nov 2002
Posts: 1289 |
I'm not able to help unless I know thoroughly your methodology and points of reference in emulating specific parameters of SID ;) |
| |
Fred
Registered: Feb 2003
Posts: 284 |
Quote: I'm not able to help unless I know thoroughly your methodology and points of reference in emulating specific parameters of SID ;)
At least it would help if you specify a list of tunes where the problem is clearly audible. The more tunes the better so the problem can be identified more easily. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11114 |
indeed. for example it would help a lot to have a bunch of standalone test tunes that show the problem. or you could even look through the resid updates and tell what revision introduced the problem: https://sourceforge.net/projects/vice-emu/files/old-versions/ |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
See this post WANTED: older (Windows) VICE builds for details on ReSID commits that actually changed things in the SID emulation.
Some of the WinVICE builds in the dir groapaz mentioned will not be the exact revision due to trunk breakage. So some revisions in the old-versions dir may be a few commits ahead, or I backported some code to get as close to the ReSID commit revision as possible. I didn't touch the ReSID code however. |
| |
xIII
Registered: Nov 2008
Posts: 210 |
Is there an build I can actually use on my Windows 10 64 bit PC ?
I don't know anything about makefiles and stuff like that... :( |
| |
chatGPZ
Registered: Dec 2001
Posts: 11114 |
use the nightly builds from vice.pokefinder.org
(also nice to see that in almost 6 months noone bothered to actually help with those filters. guess its not quite that important then afterall) |
| |
Dano
Registered: Jul 2004
Posts: 226 |
Don't know that those values are actually there for, but if i turned that filter bias up to like 2100 from -3000 it sounded way way better on tunes like "loopin" from MCH.
Can't help you with this C thing either. I just know that Vice2.x sounded better, and tools like Sidplay2.6w do too, which are pretty dated. So it seemed to worked some time ago. Who broke it shall fix it again.
Besides that i think everybody who uses 3.2 would prefer a proper sounding Vice again. And if you and the other devs don't care aswell, people will just stick with Vice versions that worked for them. |
| |
xIII
Registered: Nov 2008
Posts: 210 |
Quote: use the nightly builds from vice.pokefinder.org
(also nice to see that in almost 6 months noone bothered to actually help with those filters. guess its not quite that important then afterall)
thx |
| |
chatGPZ
Registered: Dec 2001
Posts: 11114 |
dano: i dont know what gives you the idea that we dont care. infact we spent a ridiculous amount of effort into fixing it in the last months (look on the bugtracker). however, when ppl (at least here) prefer whining over helping (and how has been told right here, it doesnt require C, it doesnt require compiling, it doesnt require understanding reSID, it only requires a bit of effort) then well... dont expect anything. the emulation _has significantly improved_ in the past few versions (look at the test programs) - however, regressions are normal and obviously need fixing. and that can only be done if ppl who think something is wrong actually tell *exactly* what the problem is *and how to reproduce it*. if you dont bother spending time on this. oh well. use 2.4 for all i care. |
| |
Pantaloon
Registered: Aug 2003
Posts: 124 |
2.4 is what i use :) lovely version :) |
| |
Pantaloon
Registered: Aug 2003
Posts: 124 |
On a more serious note, the only annoying thing i found out with the new Vice is that it seems to work bad with the windows UAC. All other problems i had in the past was solved by getting the right configuration. |
| |
Stryyker
Registered: Dec 2001
Posts: 465 |
What UAC issue? Do you have it in program files or something? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11114 |
As always, please report a bug. I have never heard about UAC issues so far. Actually, since we are now putting the config where it belongs (not in the application directory) it should work with less hazzle than before. ie it should actually work right even in the program directory :) |
| |
Endurion
Registered: Mar 2007
Posts: 72 |
That could be the same issue that's plagueing me as well with the new VICE.
After every bigger Windows update I have to re-run it with admin rights once. I couldn't find out why that problem persists. A bug has been filed for this. |
| |
Radiant
Registered: Sep 2004
Posts: 639 |
Regarding helping out; I've spent a couple of hours in total looking at the VICE sources aiming to fix a specific issue or another, but like with any sophisticated software project that's been in development for a while it's by now a rather large system of components, with a lot of technical "history" (debt). If you dive into it with the mindset of "just going to fix this one thing" then you're quite likely to give up rather quickly. I think you need to have a mindset of "now I'm going to start understanding VICE" rather than "now I'm going to fix [bug x]", because the former mindset will be more immediately rewarding.
And regarding this specific issue: When I ran into it a couple of months ago (yes, I've been quite busy with non-C64 things) I checked the bug tracker, and it looked like the problem was already being actively addressed by people with more insight into both VICE and the SID than I have, so I decided not to bother.
Should this change have gone into a a release to begin with? Ideally no; it wasn't ready by a stretch, but hey, shit happens. And while I as a user completely share the frustration over this rather sudden and hard to motivate regression, I think we'd also do good to remember the old devise: Beggars can't be choosers. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11114 |
what would really help: make small test programs that play a single note which then comes out wrong. ie triggers the bug. iterate through various filter setups, voices, waveforms. it is close to impossible to debug anything when your testcase is a tune "which sounds wrong at 1:42". |
| |
Radiant
Registered: Sep 2004
Posts: 639 |
I might do that if I can find the time (a rather scarce commodity at the moment). What do you mean specifically with "iterate through various filter setups, voices, waveforms"? To create a test program for every such combination that the programmer can think of that sounds wrong, or to be able to catch new regressions in unrelated/ok sounding parts of the SID introduced by fixing an existing one?
In my mind the latter could make a lot of sense, as a set of generic test programs in a regression test suite, but then we'd need to establish what'd be a good catch-all subset of the parameter combos. If we're going for something naïve then we're talking about a hell of a lot* of test cases, but even with a
subset of those that would maybe only be manageable with some sort of FFT based automated approach?
* Iterate over all waveforms on all combinations of voices, including controlled tests of sync bit + ring mod, for each waveform iteration, iterate over all filter combinations over all the voices, for each filter iteration, iterate over all the combinations of extreme values for cutoff and resonance, for each iteration over cutoff and resonance, iterate over a set of predetermined volume changes, and for each iteration over volume changes iterate over a set of pulse width extremes -- I think that should cover most of it, with some additional tests for line in? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11114 |
yes
=D
you see, the problem isnt only choosing what to test... for a start having those things that definately sound wrong would be good. perhaps including recordings of what it should sound like. we need to find out about the edge cases, so we know what to fix (and by we i mean leandro, i dont understand the resid code at all =P)
one big problem, unfortunately, is that we have no way to actually compare the output with the "correct" output other than by ear, especially when the filters are enabled :(
edit: you could also chime in on the bugtracker and ask leandro for what he'd like tests for. he can even write them IF you tell whats wrong and what isnt. |
