| |
chatGPZ
Registered: Dec 2001
Posts: 11357 |
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 :) |
|
... 20 posts hidden. Click here to view all posts....
|
| |
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: 468 |
What UAC issue? Do you have it in program files or something? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11357 |
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: 73 |
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: 11357 |
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: 11357 |
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. |
| Previous - 1 | 2 | 3 - Next |
