1tracker v0.47 (Page 6 of 7)

I'd need more information on this to make an informed judgement, but generally I think that's a terrain that needs to be treaded very carefully. With automatic updates, there's a risk that you'd accidentally destroy part of your work. Also, 1tracker's current copy/paste-centric approach has the advantage of encouraging variation. When I copy a section and later change some detail in one section, I'll usually apply the changes slightly differently in other copies of that section, often not even deliberately. Happy little accidents, to say it with Bob Ross. For me, it's one of the great strengths of 1tracker. I would possibly be more happy if the updates were manual, that is, you select a source block and one or more target blocks and then issue a command to sync them up.

Generally speaking, I've fully embraced the post-pattern age, haha. My latest pet peeve is actually something else - ticks. And I don't mean the ones that crawl around in the forest trying to kill you with a myriad of diseases. Yeah, those suck, too. Literally. Anyway. Having to deal with ticks aka row length aka speed is annoying. So you start to work on a melody or whatever. Now you want to add some ornaments, so you Ctrl-E that sucker a couple of times. Add yer ornaments, but now you want to save RAM so you optimize the rows. Now all your blocks have odd lengths and it becomes really hard to keep track of where the block borders should be when you move around stuff.

Leaving aside the implications of row transition noise, I think it boils down to this: You always want Speed 1 resolution (especially for 1- and 2-channel engines), but a) you don't want rows with no changes in your output data and b) you don't want all those rows cluttering your tracker view. a) can be solved by having the compiler collapse empty rows, so the big question is how to solve b). I haven't been able to come up with any good solutions yet, it's just something I keep thinking about.

Btw I believe 1tracker's RowOpt feature is wonky. The following:

Sp T
02 C-4
.. ...
.. ...
.. ...
03 D-4
.. ...
.. ...
.. ...
04 E-4

will be optimized to

04 C-4
04 ...
04 D-4
04 ...
04 E-4

which is obviously incorrect.

Hi Shiru

I use 1-tracker for all my beeper tune compositions these days and find it pretty easy to use now.
Can I request a new feature.

The ability to compile the tune to a specific address ?

All of my phaser 3 tunes have had to be relocated as they've been used in games but I usually have trouble tweaking the .asm to compile with sjasmplus so being able to compile to a user definable address would be great

cheers

Tufty

Also found the bug that causes peskysoundzx to segfault. It seems that Angelscript does not like implicit type conversions in conditionals. The following changes to peskysoundzx.1te will fix the problem:

line 542:

    if(row<int(songLoopStart))//start before loop

line 549:

    if(row<int(songLoopEnd))//start inside loop

line 748:

    if(takeLoop==1) if(row>=int(songLoopEnd)) row=int(songLoopStart);

I'm pretty sure ZXStandartExportOptions itself is called twice, but I don't know yet where those calls are coming from. While investigating, it turned out my build system is broken and can't link pthreads for some reason. So I need to fix that first.

Yep, I'm using Print, and it's called twice here. Ehhh... well, it's not causing any major issue, so I'd say let's just walk away from this one.

I can confirm that your fix made the job, I didn't understand why I had so few engines available, it was because 1tracker crashed when it reached peskysoundzx, then after a second load it didn't try to load the rest of the engines. I've isolated peskysoundzx first, until I've discovered your fix, thanks.

And thank you Shiru for making new releases of 1tracker, I should try to compose more with it!

Thanks a lot Shiru

I can't wait to convert modules from Amiga to 1tracker :-)