| |
Hermit
Registered: May 2008
Posts: 208 |
SID-Wizard - further development
Hi
I opened this new thread to discuss upcoming ideas for SID-Wizard which I released on 7 July.
SID-Wizard V1.0 RC
As you can see the source code is entirely shared, so you might contribute to the code yourself in some way if you wish.
As a starting point I'll try to make a sketch of the whole code-structure which might help to find parts of the program.
Soci gave some ideas which I think will be described soon in this topic.
thx for your great feedbacks
|
|
| |
Hermit
Registered: May 2008
Posts: 208 |
Thanks to Soci, the project is now at sourceforge and will be developed through svn.
The link to the .zip file containing the entire release:
http://sourceforge.net/projects/sid-wizard/files/
|
| |
Flavioweb
Registered: Nov 2011
Posts: 447 |
It's possible to include some kind of "pitch correction/compensation" to play a tune both in PAL and NTSC?
As discussed here:
sid timing ntsc/pal
also if speed of execution is the same, there is a pitch difference if a tune was composed on a PAL machine and play on NTSC system, and vice-versa, due to hardware difference.
So, i thought... tunes $00-$0F = composed in PAL, tune $10-$1F = same tunes but pitch-shifted for NTSC compensation.
If Sid-Wizard is PAL/NTSC compliant, there may be a flag to identify if a tune was composed on PAL or NTSC machine and the tunes from $10-$1F automagically become compensed for the other system... |
| |
chatGPZ
Registered: Dec 2001
Posts: 11107 |
what about simply recalculating the note table before starting the tune? |
| |
Hermit
Registered: May 2008
Posts: 208 |
Hi. Thanx for the idea.
I think it will be easy to realize.
My idea is to have a separate prg for ntsc mode instead of including both PAL & NTSC tables in the editor/player, because the two modes won't be swithched too frequently back & forth.
There are bytes left in the SWM format's header for later expansions so it won't be a problem at all to sign in the SWM module if the tune is PAL or NTSC, and SID export will have to support this switch as well.
The tempo and hard-restart timers should be switched automatically if e.g. a PAL editor would open an NTSC tune. That would cause differences in the sounds according to my experience with Goattracker's NTSC mode. HR timers were set to 3 (which is possible in SWM instrument-data but my player should be upgraded to support it) for some sounds and even changing the tempo was not perfectly matching but could be approached well at tempos above ~5.
(NTSC framespeed is 60Hz, so e.g. PAL tempo 5 would be 6 in NTSC mode for the same speed result.)
I'll implement this feature as soon as possible...
|
| |
Hermit
Registered: May 2008
Posts: 208 |
There are some issues I collected which are to be solved:
1. I mentioned in the comments what Ian Coog notified me:
Instrument 0 should have a pointer or better checking should be implemented in the player-code to avoid reading any pointer for instrument 0 which doesn't exist, because it can point outside the player routine and possibly could cause undefined behaviour.
2. The $FF sequence/orderloop jump/loop command's address should be verified by the player (I think it was, but I possibly left it out from the latest fixes.) At the RC release if a FF jumps to itself it causes endless loop. This is easy to fix and I still wonder how I could overlook
it...
3. I found out that tempos are not fine-tuned, e.g. Dazzler in SIDHACK33 is slower than the original in tempo5, but faster in Tempo6.
4. The hard-restart code should be verified. I think I did it correctly in the player-code but some hard-restart setups don't seem to trigger sounds well. Maybe I don't know hard-restart values enough and that's all. We'll see...
Someone who is really familiar what HR setups work well could delight me if the HR routine is good or should be improved...
5. After the latest last-minute fixes I found out that F1/F2-key initiated song-play modes doesn't read big-effects (like tempo-change) if there's no instrument in the instrument-column of a pattern at the same row. However F3 play doesn't have this issue. This will need a little fix in the initialization routine of the player I guess.
As soon I get used to the SVN method at sourceforge I'll do all the remaining fixes (I never used svn because I always developed alone). We have to modularize the code as much as possible with assembly. Soci have ideas how 64tass can be used for a degree of modularization. As soon the fixes are in place, adding the new features can follow (with a pace that my other project, building the FPGA computer can allow)...
CHR$ |
| |
Hermit
Registered: May 2008
Posts: 208 |
I found a descussion here and there's question about HerMIDI.
http://chipmusic.org/forums/topic/7702/sidwizard-10/
I'll concentrate first on finalizing SID-Wizard 1.0 version then I finish the HerMIDI interface's development. It's working but after a little while it gives up the asynchron C64-PIC connection. As soon I can stabilize its working (what I tried at the party), I'll share its documentation asap.
You have to know HerMIDI is going to be a cheap, simple fast & dirty solution, just to be able to use a simple MIDI keyboard/controller connected to C64. It doesn't even have optocoupler because it takes the operation voltage from the MIDI device's 5V whose output should have a ground-pin (2) according to MIDI specification.
A fully compatible isolated MIDI interface could be designed to USER port where everything is given, even power (which is not present in Serial/IEC port.) I'm not sure if I'll build an USER port version in the future, but for a while the Serial port solution can be better than nothing even if it's monophonic and non-multitimbral MIDI-Omni (processes every MIDI channels). USER port connector seems to be available at Ebay however I've read its occurrence is occasional... My keyword for HerMIDI is simplicity, if one needs fully capable standard MIDI interface it must possible to acquire one...
|
| |
Hermit
Registered: May 2008
Posts: 208 |
I made a graphic explanation how the source files in SID-Wizard 'source' directory relate to each other at this state. It may change what the source files contain but they are likely to stay in this layout for a while.
To ease development I'll make a flow-chart for the player-code in 'player.asm' soon...
|
| |
TSM
Registered: Jan 2007
Posts: 42 |
What about adding support for 1351 mice? |
| |
Frantic
Registered: Mar 2003
Posts: 1627 |
tsm_carmine: Ahh.. That is the kind of comment that makes me happy that I never released my own music editor. Feels so good! :) |
| |
Hermit
Registered: May 2008
Posts: 208 |
Why not... last year Clarence mentioned this to me too. Maybe me or someone else will try to add mouse-support.
One thing should be solved 1st, the multiplexing of the remaining cursor sprite...
|
| |
Frantic
Registered: Mar 2003
Posts: 1627 |
Sorry if I somehow gave a negative impression. My own laziness obviously doesn't have anything to do with your project of releasing a new nice music editor. It is good that you feel the energy pumping through your coder fingers. :) Thumbs up for the effort!
I guess I was also thinking about how Cadaver was constantly bombed with requests for new features in GoatTracker.
One nice thing about having mouse support may be that, although in the first instance it may be implemented with traditional usage in mind that relates to the GUI, it may later turn out to be a nice way of interfacing with the music when playing live in ways that was not anticipated at first. (E.g. adding an offset to filter cutoff when moving in the X-axis and adding an offset to filter freq when moving in the Y-axis, or so).
Nice graphical flowchart you posted here in the thread by the way. Is it done in some particular program which produces precisely this kind of charts‚ or did you rather "paint" it in a general purpose graphical editor? |
| |
Hermit
Registered: May 2008
Posts: 208 |
Hi.
I didn't feel any negative about your comment at all, I like to hear ideas and hints :) I'm an objective person who says exactly what thinks, and whenever there's emotional content it would be seen clearly, I never hide my emotions behind my sentences.
I really think mouse support is a good idea since Clarence told me, and a starting point is to have enough sprites on the effective screen by multiplexing. That's all I thought.
The picture above is a 'Source Dependency Tree' or the like, not a flowchart. The lookout is UML but not really following the rules of UML. I made it on paper first, then drew manually with Dia which is cross-platform and free.
I'm making a flow-chart for the player with this Dia tool as it turns out to be fine for that task. You can check it out at SID-Wizard sourceforge code's '/trunk/document/' folder (not complete yet at this moment).
http://sourceforge.net/projects/sid-wizard/
I want to see the flow-chart of my own player code to find out what to improve (e.g. HR).
I want to make it easier to join to the further development if anyone wants to participate. Our brain can understand the system easier & faster visually...
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11107 |
Quote:One nice thing about having mouse support may be that, although in the first instance it may be implemented with traditional usage in mind that relates to the GUI, it may later turn out to be a nice way of interfacing with the music when playing live in ways that was not anticipated at first. (E.g. adding an offset to filter cutoff when moving in the X-axis and adding an offset to filter freq when moving in the Y-axis, or so).
it might also be useful to enter commands in the tracker.... eg when the tune is playing, moving the mousewheel puts filter freq or cutoff commands into the pattern. |
| |
Hermit
Registered: May 2008
Posts: 208 |
Anyway, for that use the HerMIDI interface will be useful when it gets finalized, because it filters and sends pitch/volume/expression/mod-wheel MIDI messages towards C64. Actually it might give better control for sound parameters than a mouse. Mouse's main advantage would be easier window navigation, but may be a very unique tool for sound-controlling too.
Btw, if the live-performance as such will be a need, I'd suggest a special separate executable which would be specified for live-performance (like using C64 as monophonic synthesizer, what MSSIAH does already quite fine involving CC knobs.). Coding a 'Monosynth'-like application which loads SWI instruments and makes it possible to select/play them with MIDI even without GUI, could be an easy task using the existing code in the editor and player...I had this plan in mind before...but not sure if free time allows it in the near future... |
| |
Adam
Registered: Jul 2009
Posts: 321 |
hi hermit.. sid-wizard is excellent. i look forward to the next release =D |
| |
iLKke
Account closed
Registered: May 2012
Posts: 28 |
Forgive me for potentially being sub-leet, but how about providing an alternative to C64's "2 cursors 1 shift" for general navigation?
I know one can always use an emulator but that sort of defeats the purpose of a native program.
|
| |
Hermit
Registered: May 2008
Posts: 208 |
Hi. I'm afraid there are not enough free keys on C64 to use 4 of them in one place for cursor-navigation. Or do you have an idea which keys could be used for that purpose?
If we would approach with A,D,S,W keys, three of them are used as note-keys which are more important IMO. In (the sourceforge svn version) keyhandler.inc source file has a jump-table which can be modified and you can play around with different keysets. In SID-Wizard I tried to carefully select the keys so they can be used easily on real and emulated hardware too... |
| |
Hermit
Registered: May 2008
Posts: 208 |
Hi Guys.
I made a flow-chart for the player-routine of actual svn version SW (player.asm).
Hopefully it's easier to understand its workings and it will be a good help (preferably printed out) to me or others who might have optimization ideas for the player...
http://sourceforge.net/p/sid-wizard/code/99/tree/trunk/document..
As a next step I'll improve the sound-starting and optimize some rows in the code which turned out to be unnecessary.
|
| |
Hermit
Registered: May 2008
Posts: 208 |
All known/reported issues fixed, some extras (being) added, testing phase, adjusting documentation, assembling disk-sets.
Planned release for SW1 100% version: Friday 31 August 2012 :)
(exactly at svn revision 100 ; It might be the luckiest day to play lottery once in my life... :) |
| |
robozz
Registered: Oct 2003
Posts: 42 |
Actually, there are still some bugs left that could be fixed:
* I keep hearing clicking sounds when the music is playing with channels turned off (and there is notedata in the pattern) the same clicking occurs when selecting a new instument (+/- keys)
* $d017 and $d01c is never initialized.
The following is perhaps not a bug, but in the instrument panel tables (F7) the previous position of the cursor is never saved when using the ctrl-key, it is always at top left. It would ofcourse be much better if it was saved.
About the manual, I had to look in the source code to find certain keys, since neither channel on/off (shift+1/2/3) nor pulse/filter reset on instr. notestart (cbm+P/F) is mentioned there.
Finally, regarding the use of the space key. I think this key is better suited to delete notes/data, it it more "standard" :) having to use key 1 or A just seems awkward. Also there should be a much clearer indication of which mode is active, the slow vs. fast flickering is almost indistinguishable.
|
| |
Hermit
Registered: May 2008
Posts: 208 |
hi robozz
1. Leticia alse told me about the clicks on 6581 chip, but after some investigation I found out this is the filter-switching and cannot be avoidable. It wasn't an issue with tunes/trackers that only used 1 cannel permanently for filter. If you use 6581 where this click is much stronger you shouldn't mix filtered/unfiltered instruments on one channel. Further clicks can be heard if the instrument-table switches filter-type (lo/band/hi), and what's more: sudden cutoff-changes cause clicks too. Instrument-selection now initializes tables, that's why the click on 6581 chip when alternating between filtered/non-filtered instruments.
That's coming from hardware, I cannot do anything with it, but maybe some experienced 6581 composers can tell great ideas/workarounds for that...i use 8580 and clicks are slight. Just in case, I made big-FX $1F toggle filt-external bit of SID, but it has effect on SID-noise only, doesn't play role in the clicking.
-There were clicks in the RC version caused by the strong/staccato hard-restart-type (forcing testbit on HR frames), but it's switchable and much less used now in the demotunes (at svn) as HR improved meanwhile.
2. Thanks for notifying me that VIC initialization is incomplete. I'll take care of that with $d017 ard $d01c.
3. Well, CTRL between instrument tables was intended to be like this. But as it's important for you and might be important for others I'll try to improve it, not much memory overhead, just some more bytes to buffer cursor-positions...
4. I wonder how I could forget to mention those really important key-combinations (mute, Pulse/Filter-reset on/off), but I'll include them asap in the manual. Also some other details need to be fixed in the manual, like bigFX $0F, some added extras (e.g. bigFX $1F), and HerMIDI status.
5. About SPACE: I think it's used in many programs to toggle edit/jam (FT2,GT), I wouldn't change it in this release, or can you suggest an alternative key which would suit better? Luckily the key-routines can easily be edited in jump-tables of the source-code.
I'll sort out something to sign the 'edit'/'jam' modes better. Could you suggest something? changing border colour might be too strong, maybe I'd make bigger difference in cursor-blinking (i didn't want to give rushed feel with fast blinking cursor), or colourize something else on the screen...
I selected key 1 an A, which are not note-keys as 'delete without moving the rest back' because there was no key left after used back-space for 'deletion with moving the rest back'. Maybe C= + Delete should be freed up for this (which currently deletes instrument+FX on a row)
|
| |
robozz
Registered: Oct 2003
Posts: 42 |
Hello.
(about the clicking)
Ok, that explains it a little better, I switched from 6581 to 8580 in VICE
and the clicking disappeared! :)
But it would ofcourse be better to be able to use the editor even with 6581 :)
I still don't quite understand why there should be clicking noises when the
channel itself is completely turned off, can't you just bypass all writes to
the filter registers?
Quote:Well, CTRL between instrument tables was intended to be like this.
I figured that since positions get saved when you switch between the pattern
window and all the other tables (instrument, orderlist, chord and tempo) there's
really no reason for it not to behave the same way in the instrument tables.
Quote:About SPACE: I think it's used in many programs to toggle edit/jam (FT2,GT), I wouldn't change it in this release, or can you suggest an alternative key which would suit better? Left arrow maybe? it's unused as far as I can tell.
The way I see it, the purpose with the jamming mode must be to not allow editing, right? This only works as long as you place the cursor in the first column (where the notes are) If you type any hex values in the other columns, or in the instrument tables, it doesn't work.
One thing that stands out with this editor compared to some others I know of
is that note jamming is always on even though you're in "edit mode" so to speak.
so what's the purpose of the jamming mode? :) |
| |
Hermit
Registered: May 2008
Posts: 208 |
Here we go...
SID-Wizard V1.0
Further development will be based on recent feedbacks (collected in source/TODO.txt) and upcoming feedbacks... I won't promise to be fast but i think I'm not the only one suffering from small amount of free hobby hours...
Let's test now by making tunes ;) |
| |
Stainless Steel
Registered: Mar 2003
Posts: 966 |
I'd love to give it a try, but i'm severely struggling with the keyboard layout (i'm sdi hardwired).
I read that the keyboardlayout can be customized, how about a sdi layout ? :-D
|
| |
Hermit
Registered: May 2008
Posts: 208 |
Hi,
I checked SDI layout... it's very different system but you're right, "source/include/keyboard.inc" contains a jumptable around row100 where key-functions can easily be exchanged before assembling...
But in this case it's not very simple, I found some SDI keyboard-commands that don't have a substitute yet in SID-Wizard and would require some additional code too (which will be useful till memory allows it). On the other hand there are some functions in SID-Wizard that wouldn't have too much remaining obvious key-combinations if some keys were occupied for SDI (or other kind of) layout. (I designed the original keyset is very carefully to be usable in VICE as well.)
Anyway, I'll include this in the 'source/TODO.txt', and if free-time allows it at the end we'll have a switch in 'source/settings.cfg' to change keyboard configurations (GMC/DMC/JCH/X-SID/SDI/etc.) at least partially...
(As long-term plans the colour-scheme and keyboard-layout, etc. should be configured/preselected in the running application...)
thx for the tip...
|
| |
tlr
Registered: Sep 2003
Posts: 1714 |
Tiny patch to fix and extend relocation range in the sid-maker: sw10_export_range.patch |
| |
Hermit
Registered: May 2008
Posts: 208 |
Thanx, tlr... it surprised me that $0200 is a valid export-location but maybe it's used in demos and I was unaware about this. (I never needed to go below $0800 with music:)
Yesterday on real c64 I found that on REAL C64 the keyboard-handling in SID-Maker skips over relocator-setting. This is probably due to the bouncing-noise of C64 button when pressed, and a small button-noise-debouncing delay (some milliseconds) should be added there.
Conclusion: I should never upload C64 release before testing it THOROUGHLY on the real stuff. I learned that now. In VICE the buttons were noiseless, and there it worked properly (and therefore fooled me it doesn't need delay). This will be the 1st thing I'll fix in the svn version.
If you'd like to participate in the development with codes like this one, you're welcome. If you think so, e-mail me to my new address hermit@hermit.netne.net and we'll grant you write-permission for the svn trunk...
thx again ;) |
| |
Stainless Steel
Registered: Mar 2003
Posts: 966 |
Something i wasnt able to find in the docs, how do you mute a channel ?´
Also the sdi keyboard "emulation" wouldnt have to be 100%. |
| |
iLKke
Account closed
Registered: May 2012
Posts: 28 |
@Stainless:
Quoting robozzAbout the manual, I had to look in the source code to find certain keys, since neither channel on/off (shift+1/2/3) nor pulse/filter reset on instr. notestart (cbm+P/F) is mentioned there.
RTFT :) |
| |
Hermit
Registered: May 2008
Posts: 208 |
You probably checked the older manual of the RC version where I forgot to mention these keys somehow.
In the new (1.0) manual I added the missing key-combinations..
http://noname.c64.org/csdb/release/download.php?id=138590
SID-Wizard V1.0
|
| |
Stainless Steel
Registered: Mar 2003
Posts: 966 |
btw awesome work hermit.
oh and if follow-along play would be default instead of how it is now would be even more awesome :-D |
| |
Hermit
Registered: May 2008
Posts: 208 |
Thx, Stainless - the 'follow-play by default' sounds like kinda FT2 playback, but I always liked better if I could edit a music while listening it...(and in SW follow-play doesn't allow any editing because it might cause data-corruption due to the slower refreshment of screen-data and positions...)
Meanwhile I had some advances (mainly fixes, and 1-2 additions), the sourceforge svn repository holds compiled binaries...
@Robozz: now the cursor-positions are remembered in the instrument-tables. (But of course positions are reset on instrument-change to prevent being in illegal table-area.)
The next planned release is 1.2, as I'm going to do quite some additions in a short while. (and pixelated '1.2' looks better than pixelated '1.1' ;)...
thx for all your feedbacks before & after this post... ;)
|
| |
BrandonWalsh
Account closed
Registered: Jul 2011
Posts: 6 |
Quote: Thx, Stainless - the 'follow-play by default' sounds like kinda FT2 playback, but I always liked better if I could edit a music while listening it...(and in SW follow-play doesn't allow any editing because it might cause data-corruption due to the slower refreshment of screen-data and positions...)
Meanwhile I had some advances (mainly fixes, and 1-2 additions), the sourceforge svn repository holds compiled binaries...
@Robozz: now the cursor-positions are remembered in the instrument-tables. (But of course positions are reset on instrument-change to prevent being in illegal table-area.)
The next planned release is 1.2, as I'm going to do quite some additions in a short while. (and pixelated '1.2' looks better than pixelated '1.1' ;)...
thx for all your feedbacks before & after this post... ;)
How do I make it so that it also inputs the current instrument number? Right now it just goes "C-4" and then I manually have to enter the instrument number in the instrument column. What did I miss? :) |
| |
iLKke
Account closed
Registered: May 2012
Posts: 28 |
Quoting HermitThx, Stainless - the 'follow-play by default' sounds like kinda FT2 playback, but I always liked better if I could edit a music while listening it...
Here's food for thought. There could ba a switch with an on-screen indicator (like for example the EDIT/JAM switch) for follow on/off. Then you only need to press F1 regardless of your preferred mode, and it would still be easy to switch modes. This is similar to how Renoise does it.
Personally I have no preference here. Just suggesting a flexible interface solution based on what you guys were discussing.
As a separate thought, perhaps it would even be possible to do this:
1-in follow mode, press play
2-song plays with follow
3-hit follow switch button, song keeps playing but stops following and you can now edit any part
4-hit follow switch again to start following again, while the song is playing the whole time
Would be comfy, no idea if technically doable tho. |
| |
Hermit
Registered: May 2008
Posts: 208 |
Hi
@BrandonWalsh:
That 'type instrument automatically' feature is already requested and have been put the TODO.txt list. Possibly I'll be able to implement it today or in some days. Btw. I don't think it's the default behaviour of most music editors, but is useful for sure.
I'll have to think if it's better to put the instrument numbers only when needed (you know, when you select an instrument once it remains until changed further), or optimize it upon saving the workfile.
On the other hand in SID-Wizard selecting an instrument resets the Pulsewidth-/Filtertable pointers for the instrument and is a handy feature to reset intstruments which has PW/filt. reset switched off by C= + P or F keys...
This won't be the default behaviour but will be selectable by pressing Shift+I key-combination, and will be remembered in the worktune as a setting just like mute/auto-advance/framespeed/etc. settings...
Or you might have better idea for the implemantation of this function, in that don't hesitate to share with us.
@iLKke: The 'follow-play on/off' switch is a good idea. That setting could also be saved into the workfile as a preference. Also there was some complaints about the flickering rasterbars, that is another setting too which should be selectable (display just one-row rasterlines but not changing $d021 for the whole rastertime). Some people gets annoyed about the playback-rasterbars, I can understand that...
These are in the TODO.txt list... I guess SWM1 format will be maintainable with these added settings because the default settings were and will be saved as 0 in the worktune's headers... SWM2 module format will come when substantial changes happen in the music-data...that will be a bit later I guess...
I'll post it here when these functions get implemented in the svn trunk... |
| |
tlr
Registered: Sep 2003
Posts: 1714 |
In the svn repository all source files are marked as binary making diffs between commits unavailable in the web view.
Could you please mark the relevant files as text? |
| |
Hermit
Registered: May 2008
Posts: 208 |
Hi. It seems Soci corrected the sources to 'text' MIME type under revision 106.
In revision 107 I made it possible to fast-call the instruments' default chords when pressing return on them in instrument-panel.
Also made a default instrument to be on the clipboard at startup, and now instrument-copybuffer isn't cleared after init/load. Also I fixed that instruments weren't reset after paste/cut procedures.
|
| |
robozz
Registered: Oct 2003
Posts: 42 |
Quote:@Robozz: now the cursor-positions are remembered in the instrument-tables. (But of course positions are reset on instrument-change to prevent being in illegal table-area.) Nice! :)
Quote:That 'type instrument automatically' feature is already requested and have been put the TODO.txt list. Possibly I'll be able to implement it today or in some days. Btw. I don't think it's the default behaviour of most music editors, but is useful for sure. I wonder if this 'type instrument automatically' feature really is such a good idea? If you just want to change the note, the instrument column will be destroyed this way.
Quote:This won't be the default behaviour but will be selectable by pressing Shift+I key-combination, and will be remembered in the worktune as a setting just like mute/auto-advance/framespeed/etc. settings...
Ah... good :)
Hmm.. there seems to be a bug when setting instrument without there being a note in the same row.
In the example below, selecting instrument 02 with no note will mess up the sound of instrument 01 currently playing.
C-4 01
...
...
...
... 02
...
...
...
C-4 |
| |
iLKke
Account closed
Registered: May 2012
Posts: 28 |
Quoting robozzHmm.. there seems to be a bug when setting instrument without there being a note in the same row.
In the example below, selecting instrument 02 with no note will mess up the sound of instrument 01 currently playing.
C-4 01
...
...
...
... 02
...
...
...
C-4
And what exactly would you want to happen when you do that? |
| |
Conrad
Registered: Nov 2006
Posts: 833 |
Quote: Quoting robozzHmm.. there seems to be a bug when setting instrument without there being a note in the same row.
In the example below, selecting instrument 02 with no note will mess up the sound of instrument 01 currently playing.
C-4 01
...
...
...
... 02
...
...
...
C-4
And what exactly would you want to happen when you do that?
It's a way of optimising pattern data :) For example, you might have a lead pattern, but you have more than one instrument set up for that particular sequence. To save memory, set up a pattern like this:
PATTERN 1: (with no instruments set)
c-3
---
---
---
c-4
---
c-3
---
---
Then before the beginning of that pattern, the last instrument value played from the previous pattern will be used (if that makes sense.) It saves you having to copy and paste the same pattern data but replaced with another instrument number.
...
I would like to see that "bug" fixed too, as it's a trick I use in many of my tunes. (not that I can't live without it. :)) |
| |
robozz
Registered: Oct 2003
Posts: 42 |
Quote:And what exactly would you want to happen when you do that?
------------------------------------------------------------
It's a way of optimising pattern data :) Actually I was thinking of something else, but this is ofcourse another situation where this bug will be heard.
What I had in mind was this situation:
C-4 01
...
...
... 02
C-4 5x (sustain change $50-5F)
(or some other effect on the same row as the note) but then I realized that it is possible to do it this way in SID Wizard:
C-4 01
...
...
...
C-4 02 5x
the first example is how it would look like in editors like SDI, I forgot about the additional columns in SW :) |
| |
SIDWAVE
Account closed
Registered: Apr 2002
Posts: 2238 |
I think you should organize a sid wizard tune compo, and get some people actually using and learning to use it.
i just see a bunch of open source developers, with their dream to make the ultimate software, but nobody is making music! :) |
| |
Soren
Registered: Dec 2001
Posts: 547 |
Conrad: I do that in BullSID aswell... just having plain notes and perhaps effects in some sequences... setting instrument in previous sequences. ;-) |
| |
tlr
Registered: Sep 2003
Posts: 1714 |
trunk r149:
Assembling file: editor.asm
Assembling file: settings.cfg
Assembling file: SWM-spec.src
Assembling file: include/irq.inc
Assembling file: include/displayer1.inc
Assembling file: include/player.asm
Assembling file: include/playadapter.inc
editor.asm:230:38: fatal error: can't open file include/startupmenu.inc: No such file or directory
Error messages: 1
Warning messages: None
Passes: 1
Memory range: None
make: *** [../binary/SID-Wizard-nopack.prg] Error 1
missing file in repository? |
| |
SIDWAVE
Account closed
Registered: Apr 2002
Posts: 2238 |
open source sucks. coder 1 dont know what coder 2 does, bugs appear, planless development with "great" ideas.
its better if hermit know what he is doing, and nobody interfere. |
| |
Mace
Registered: May 2002
Posts: 1799 |
SIDwave, open source is why Linux never became big, right? |
| |
SIDWAVE
Account closed
Registered: Apr 2002
Posts: 2238 |
big ? 100+ distros, unpossible to choose what to use, and when you do, there is a new update every day ?... |
| |
Hermit
Registered: May 2008
Posts: 208 |
Hi Guys
Glad to see your interest.
I'm surprised about the fact that the newly added 'startupmenu.inc' isn't in the repo.
If you check out the repo through web-interface, revision 150 contains the file in the list:
http://sourceforge.net/p/sid-wizard/code/150/tree/trunk/source/..
Anyway, according to my experience, sourceforge svn interface has some unreliable things. Sometimes it took some days to see my latest additions through the web-interface and sometimes the trunk version number is very misleading (even went down to around 20 at a time...)
Fortunately at least the core of the svn seems reliable...
About open-source: I like the good side of the open-source, that everything is free, and sometimes really good stuffs can be found. But I agree that teamwork can show some difficulties (especially in assembly), that's why I first code things myself and when the base is ready more or less, and the concept is clear, a help from anyone comes handy.
It was a good experience to work together with Soci for a while after SW went to svn, that was my first time of online open-source teamwork...
(And now Conrad and me will have a little surprise for you if everything goes fine.)
The 1.2 release is coming very soon, but I want to make some example tunes and finish the startup-menu to avoid too many executables in the binary folder :)
Now it supports NTSC since yesterday to a great degree in the editor... The PAL/NTSC detection (in commonsubs.inc) was based on Ninja's code, but I just coded an even simpler (and I guess reliable) method, that doesn't have to check IMR register, just plain $d011,$d012...
detect sei ;hermit's PAL/NTSC/etc detector...
bit $d011
bpl *-3 ;wait for upper screen region above rasterline $100
- lda $d012
cmp $d012 ;wait for 1 rasterline (no matter what CPU speed it is :)
beq *-3
bit $d011 ;check if we reached 0..$ff raster-region again
bmi -
sta max_rasterline_low_byte ;the Accumulator here contains the last rasterline that was before $100
...
;the resulted values in Accu.: PAL/Drean:$37, NTSC:6, old NTSC:5
Maybe something like this has been coded already. This way I'll be able to detect some more types and still free up some memo (unless this code turns out to be unreliable)...
|
| |
tlr
Registered: Sep 2003
Posts: 1714 |
@Hermit: Great! I was just trying to build the current wip.
@SIDwave: ? |
| |
tlr
Registered: Sep 2003
Posts: 1714 |
Quoting Hermit
detect sei ;hermit's PAL/NTSC/etc detector...
bit $d011
bpl *-3 ;wait for upper screen region above rasterline $100
- lda $d012
cmp $d012 ;wait for 1 rasterline (no matter what CPU speed it is :)
beq *-3
bit $d011 ;check if we reached 0..$ff raster-region again
bmi -
sta max_rasterline_low_byte ;the Accumulator here contains the last rasterline that was before $100
...
;the resulted values in Accu.: PAL/Drean:$37, NTSC:6, old NTSC:5
Maybe something like this has been coded already. This way I'll be able to detect some more types and still free up some memo (unless this code turns out to be unreliable)...
Your first stop before inventing anything new would be: http://www.codebase64.org/doku.php?id=base:detect_pal_ntsc
by J0x:l1 lda $d012
l2 cmp $d012
beq l2
bmi l1
;) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11107 |
Quote:coder 1 dont know what coder 2 does, bugs appear, planless development with "great" ideas.
so what exactly is the difference to a closed source project then? =)
Quote:Now it supports NTSC since yesterday to a great degree in the editor... The PAL/NTSC detection (in commonsubs.inc) was based on Ninja's code
as for the editor, i would simply compile two binaries and not bother about detecting anything at runtime.... wasted time and effort it is =) |
| |
Hermit
Registered: May 2008
Posts: 208 |
tlr: wow, this is really awesome short TV-system detector. Scene knowledge kicked in here and came very well :)
l1 lda $d012 ; l2 cmp $d012 ; beq l2 ; bmi l1
Lol, I wonder how I haven't come across it after some googling. (And I wonder why assemblers don't use the ; , or some other separator to group commands in one single row.)
@SIDwave: I know what you're talkin' about, in the past I tried a hundred bunch of Linux distributions and variants. Linux is still not perfect as the underlying mainstream hardware is kinda shit too ('Neumann bottleneck' caused by slow RAMs, cache/buffer 'workarounds', pipelining, etc.). Btw now I have a MacMini and I use Lubuntu on it, good combination with low noise and power consumtion, and small size. Still far from my ultimate platform - the planned parallel architecture - (sometimes Lubuntu even slows down in simple text editor too), but Lubuntu is what I like the most of all. The power of Ubuntu 'comfort' with much lightweight GUI. (In the past I used puppy linux, that's great too, but less 'user friendly' so to speak...)
@Groepaz: What I'm trying to do is to have the different player/driver versions (normal/light/medium/extra) in the same app. It's not new idea of mine after all, e.g. JCH editor can load different player versions IIRC. What I'll do that I include all of them in one binary (until it's easy to handle the binary-size under different circumstances). Coz only the player is the difference between the versions in the 'binary' dir. On the other hand some guys reported that they would like to have different frequency-tables (some prefer DMC's, and some wouldn't use equal-tempered scale in some musical keys), and that'd be a really nice feature from musician point of view to be able to select/load players/frequency tables. I'll see what I can do about it...
The best solution still would be to be able to assemble player.asm on the real C64 and optimize code on-the-fly where possible, but I don't know about a suitable assembler that I could build into the programs, that would identify at least '.if' directives...if someone points out something useful it would be great...
|
| |
Hermit
Registered: May 2008
Posts: 208 |
Well...you know I released SID-Wizard 1.2 some days ago, thanx for the nice comments & votes.
SID-Wizard V1.2
I added some features that were wished here in this forum, and more to come till it fits into the memory of C64 ;)
The feedback is really appreciated and needed to improve (and not to overcomplicate) the tool into right direction. Especially because I don't have too much time yet to test in practice, I'm trying though. Thanks to Necropolo who tested it a lot and reported possible bugs and created the majority of the example tunes. Testing is a very important (if not the most important) part of the development.
And special thanks to the new CSDB member WitchMaster for 'Creating Chip Tunes with SID-Wizard' and the fast reference charts/cheat-sheets.
Creating Chip Tunes with SID-Wizard
Charts and Tables for SID-Wizard V1.2
At the moment I'm taking some relaxation with other activities to continue then with fresh brain...
The plans for the near future - end of this year:
SID-Wizard 1.4 will possibly come out around Xmas with these significantly new features:
-sng2swm will be finished soon
-due to memory constraints I'll have to optimize the editor-code, and player-code too of course. Some help would come well in this area, I might not be a good code-optimizer. Soci helped me a lot already to simplify keyboard-handling, especially key-repeats.
-improved keyboard-navigation, maybe use of mouse/joystick to go into panels/windows/tables
-some more keyboard layouts (not just note-keys but function keys too)
-support for 2 SIDs - the interface will only show 3 channels/tracks at a time but they'll be scrollable sidewise or up/down in orderlist.
-native help-text as a .prg executable on the disk
-some more frequency tables (e.g. Verdy tuning at 432Hz, non-equalTempered) will be calculated on-the-fly (in start-up menu) after selecting tuning and musical key...
-I'll finalize the promised MIDI-hardware. First the easy-to-build simpler monophonic one, than I'll go for polyphonic too for full composition/performance experience.
-Metronome...in case the composing starts with the solo-melody theme
-The Video tutorial. And at last I'll translate the manual to Hungarian as it was requested at Arok Party.
that's it for now ;)
Sould you have any ideas or you experience problems you can still post it here...
|
| |
SIDWAVE
Account closed
Registered: Apr 2002
Posts: 2238 |
forget all about joy/mouse stuff, it will make things bad.
IMO |
| |
Frantic
Registered: Mar 2003
Posts: 1627 |
@Hermit: Not sure if it helps, but Turbo Macro Ass (in contrast to Turbo Assembler) has pseudo opcodes like:
.IF
.IFNE
.IFEQ
.IFPL |
| |
Hermit
Registered: May 2008
Posts: 208 |
Thx, frantic.
Accidentally I just checked it yesterday and it really has. My problem is that I couldn't find a source at 1st glance, and from this macro-assembler I only need the assembler part without the editor code.
The other issue is that I'm not sure if the source-code (stripped from the comments of course) will fit into memory together with the assembler-code beside the music data which can be very big in cases. Possibly it would fit, because there would only be one instance of the player (source) and relocation-tables wouldn't be needed in that case.
The biggest benefit without doubt would be the .IF .ENDIF to leave out the code-parts which are unused in the music.
If this reloc.-table solution remains TLR told me another good idea, to generate the reloc. table by code, not by hand. If the assembler (64tass) itself would be able to generate a list with the absolute-addressing instructions that would be the best.
Btw, there's another issue with the code-optimization: If timing changes due to the optimizations, it can be enough to make the exported tune sound differently than it was in the editor with the full player.
there could be a workaround to solve that, namely using ghost-registers. This is the way GT can export the tunes to sound the same as the edited version.
At the moment in SW It's guaranteed to sound nearly the same because the 4 player-types are compiled the same way as they're in the editor (however in editor zeropage is extensively used for the player to compensate timing differences caused by the injected editor-related code, badlines and cursor-sprite.)
In the current player.asm the big-effects are arranged in a way that the most used are in the beginning and the less used are at the end, so it wouldn't be hard at this point to cut down the unnecessary big-effects from the compiled player in SID-Maker and get a considerably reduced player-size.
good to have some brainstorming around this topic because the resultant music's size and rastertime can be very important after all...
|
| |
SIDWAVE
Account closed
Registered: Apr 2002
Posts: 2238 |
deleted |
