Search options (Page 10 of 137)

In LSDj, tempo is governed by the timer interrupt. In addition There are 5 raster interrupts per screen refresh that are used for sample buffer refresh and HF vibrato/pitch slide. Because the timer interrupt is not synchronous to the frame rate, it can happen at any time, even during VBlank. Johan made the decision to make the UI run in the main thread and use a counter to communicate that a VBL interrupt had happened. The interrupt does almost nothing more than increment the counter, and the mainloop decrements the counter every time it has processed one UI frame. This means that when the program is out of CPU power, the UI will suffer first.

I might do this at some point, but I don't consider very important. Let me explain. One of the main goals of littleFM is increased data security. That's why it has flash saving. Apart from expanding the memory, it also serves as non-volatile backup if the cart battery should fail. That's why the load function has strict error checking, and will abort loading the file if it finds any errors. Errors that would go undetected with the regular file manager. (Side note: LSDj did add some sort of error detection on song load just two weeks ago, but I haven't had time to look at exactly what it does.)
I don't see any similar benefit from adding song saving. It would mostly only make song saving faster. (3 seconds to save a typical song probably isn't unrealistic as a goal.) That is not to say I will never implement it, just that it doesn't obviously have as much benefit as the current existing functionality.

Did you report this when it happened? I'm always looking to improve the program.

Same with this, why didn't you do a feature request to the dork who made it?

Drill a small hole in the guide column for the button and light it from the side using one or more SMD LEDs maybe?

If joe schmoe does his own electrical wiring in his house, is he (momentarily) an electrician?

Honestly, I think "Many chipmusicians have become conceited in their old age?" is almost the definition of pernicious.

It depends on what you're looking for, again. I didn't pay for my license, so I can't say from the bottom of my heart that it's absolutely worth $75. (And no, I didn't pirate it. I got my license for free since I was a beta tester. ) It does what it says on the box, which may or may not be what you want.

That's an interesting economic point. It might be possible that they would get more than double the number of users if they halved the price (say) but it may have unintended consequences. The lower you set the price, the more likely you are to attract bottom-feeders who are not really interested in the software. And all of a sudden you have a bunch of silly support questions. I only wanted to make this one SID sound. How do I make this sound? This program is too complex. Can't you make it simpler? Why is the sound so clicky? On second thought, I want something that sounds GOOD not something that sounds realistic. Can I have my money back, please? And so on. A high price can actually be a benefit because it makes the demand for the program self-limiting to those who are genuinely interested in what it has to offer. The high volume proposition works very well for someone making plastic doodads to be sold in supermarkets, but not for every product.