SyntaxBomb - Indie Coders

Quote from: Midimaster on December 04, 2024, 07:20:51Then reduce the zone size from 150 sample points to 50  or 15 and listen to the quality now.

To clarify: Yes it is inaudible if I continue with a significantly different frequency (such as going from a C to a D). - But if I use this method trying to simply extend the duration of a note by adding another note of the same (or almost the same) frequency after it, then I hear it - not as one continuous tone, but - as two very distinctly seperate tones with an audible drop between them. And in that case it doesn't seem to matter how short the fade-out-and-in is. The drop between the two secitons remains audible because the continuity of the wave is interrupted.

That's why I suggested, if possible, going for a solution based on just making sure the sine wave of the played note always start and end on the zero-line and going towards consistently either a wave top or wave valley. Because that way one could in theory extend the wave seamlessly with the next note.

You still wrote nothing about what you are targeting with your tones... This would help immense.

And I asked myself, why you are not doing your plan? Finding the ZERO-CROSS is easy.

Are these tones SINUS or Audio?
Why not use my oscillator-model?
Why do you use short snippets to build long tone?
Why not use too long samples and cut them when time is over?


Also a possible way:

When we doing HUM-windows (e.g. for a slow-down a song without changing the hertz ) we do it with overlapping th snippets in the zone of fading.

called: Crossfading

means the new tone start 5msec too soon, when the fadezone has a length of  5msec or 200 sampleticks

please report more details...

Quote from: Midimaster on December 04, 2024, 18:39:52You still wrote nothing about what you are targeting with your tones..

Well. Since you ask.. Having just installed- and started using SmallBASIC a couple months ago, I was broadly checking out different aspects of especially sound and graphics capabilities of SmallBASIC, just to get acquainted with what I had to work with. And I had in mind - as a kind of learning project for myself - writing some kind of little 80s style arcade game including some nice graphics, sound effects, and some trailing music, within the limits of what SmallBASIC can perform.

As a side-quest under that general aim I found that in order to get any music to play in the first place I needed to write some kind simple keyboard and music editor for me to compose the tunes on and translate them into playable strings. So I started on that project, but that's when I ran into the problem of the PLAY and SOUND commands not working right.

Thus, as for "what I'm targeting with my tones": my scope is strictly within the SmallBASIC environment. But within that scope, apart from the immediate here-and-now work on my keyboard/music editor program, my target is just in general being concerned that the PLAY and SOUND commands will work as they're supposed to for when I need them.

Quote from: Midimaster on December 04, 2024, 18:39:52Why not use my oscillator-model?

As I understand it runs in BlitzMax - whereas my concern is what I can do in SmallBASIC..

Quote from: Midimaster on December 04, 2024, 18:39:52Why do you use short snippets to build long tone?

The only reason I was using audacity at all, was in context of investigating what was going on with the tones generated by the PLAY and SOUND commands. - And likewise, when I was generating snippets of tones, stringing them together, it was strictly for the purpose of testing your suggestion (which suggestion I assumed, at the time, was to Chris, in his effort to get the PLAY and SOUND commands to work right) on how to fix the issues with the sound. - In that context I was simply concerned that I would prefer to keep the possibillity that exist in the latest beta, of stringing tones together as a way to create volume fades or gradual changes in pitch. - Within using SmallBASIC..

I do not intend to actually use any externally generated tones in any project. I was simply testing how what you suggested would sound like, in the hypothetical case that Chris were to implement them into how SmallBASIC generate tones. (again: as I was concerned with preferably not losing the possibility gained in the latest beta update; making it possible to use successive short tones to create gradual changes in volume or pitch).


In short: I'm just concerned with getting the PLAY and SOUND commands to work right, so that I will be able to use them-, and the result will sound just reasonably ok, when writing SmallBASIC programs in the future. - It's not for one project in particular.

I hope this cleared up the confusion.