ChipMusic.org - Chipsounds 1.6 beta release (videos)

Re: Chipsounds 1.6 beta release (videos)

2012-09-22T10:28:18Z

9H05T wrote:

agreed. especially when you're going for 16 or 32 byte single cycle samples to make tiny mods/xms like back in the day.

To complicate matters, in chipsounds all bit patterns are assumed to be a period, so thats why you see stuff like transpose=-95 in there for LFRSr , or amiga samples.

Re: Chipsounds 1.6 beta release (videos)

2012-09-21T16:59:46Z

agreed. especially when you're going for 16 or 32 byte single cycle samples to make tiny mods/xms like back in the day.

Re: Chipsounds 1.6 beta release (videos)

2012-09-21T16:38:35Z

That could help but wouldn't solve the problem. I agree this is a complicated matter, but many times, as I said, the root note the sample is on doesn't necessarily mean it's actually that note, for example in breaks. Also, if you have a bunch of equally detuned notes, yu may never realize your mistake unless you have pitch perfect hearing. I bet a load of people back then just got samples from external sources and used them, regardless of what notes those were.

Re: Chipsounds 1.6 beta release (videos)

2012-09-21T16:34:25Z

just look in the mod for what root note the sample was on and hack the sfz accordingly. I've had this problem a bunch as I trade single cycles between chipsounds milkytracker and sunvox to make my music, all assume different root notes and so a lot of sample tuning has to be done manually. when resampling is involved (in milkytracker and sunvox) it further complicates matters. I've been hacking chipsounds sfz since day 1 I'm tommorow on the chipsounds forum.

It's not a chipsounds problem it's a problem inherent to tracked music in general. I get around this by renaming my sample with root notes so I can adjust quickly.

Re: Chipsounds 1.6 beta release (videos)

2012-09-21T09:51:59Z

If the sample was 'raw' there was no way to tell. If it was IFF, it had an internal sample rate, but no "root pitch", in any case the tracker wouldnt know the supposed pitch of an imported sound.

Its still an issue with any sampling/instrument engine. Although the samplerate of the imported file is always known (wav, aiff, etc alwyas has that), but seldom are other chunks filled with good info (smpl/inst chunks comes to mind) with root pitch for _that_ sample, so you need to tell the sampler what it is. In SFZ, for instance, thats what the pitch_keycenter opcode is.

Re: Chipsounds 1.6 beta release (videos)

2012-09-19T01:24:41Z

I think it "did", I mean, the sample has a specific sample rate in Hertz and this should tell you which note it was sampled at. This doesn't mean the sample plays at that note, though... I could sample a C-2 in F#3 if I wanted to (and that would be a massive mindfuck, but it's possible)

Re: Chipsounds 1.6 beta release (videos)

2012-09-19T00:08:22Z

As I mention in the docs, my understanding of the situation:

"Tuning woes: Mod trackers usually didn't enforce a match between a sample and its root key. In the day, when you imported a sample, trackers assumed that its sample rate was 8363Hz and that its root key was C4, regardless of its real internal pitch. For instance a mod track could have been started with a sample containing an F, even though the tracker would assume it was a C. When importing any mod/med/iff file, be aware that you might have to tweak the tuning of each slot manually (using 'Trans' and 'Tune') to match the tuning of other slots."

You can retune the sample, just like you did while importing a sample. The tracker couldnt know what the root pitch was supposed to be right?

Re: Chipsounds 1.6 beta release (videos)

2012-09-18T18:25:51Z

I just thought of something, David...
When Chipsounds loads an IFF file or IFF files from a MOD... In which note does it assume the samples go? Because in the world of Amiga samples, a lot of times, samples are not landing in C, but rather in other places. For example, breaks or loops usually are recorded at the maximum note possible for best sampling rate (F#3 if I am not mistaken).

Of course this is a major problem with most Amiga samples, and one I thought would be worth addressing, otherwise Chipsounds could be detuned compared to other VSTis you can use alongside it.

Re: Chipsounds 1.6 beta release (videos)

2012-09-17T22:26:02Z

!@!!!!!!!!

Re: Chipsounds 1.6 beta release (videos)

2012-09-11T16:19:40Z

We have just updated chipsounds to 1.601 to solve a few issues, including the IFF stuff akira^8GB found:

http://chipsounds.s3.amazonaws.com/WIN_ … v1.601.exe
http://chipsounds.s3.amazonaws.com/MAC_ … v1.601.pkg

Revision History

chipsounds v1.601 Sept 11th 2012
*Windows x64 build not working under some Windows machine (missing msvp100.dll )
*IFF import now supports 8SSP and RAW format
*YM2149F Hardwave and Sync Buzzer fixed

Re: Chipsounds 1.6 beta release (videos)

2012-09-11T11:09:10Z

Oh forgot to say I only tried this on Windows 7 64-bit. Didn't try the OSX version.

Re: Chipsounds 1.6 beta release (videos)

2012-09-11T10:30:22Z

Superb, thanks for trying it up.

Re: Chipsounds 1.6 beta release (videos)

2012-09-11T10:23:45Z

So far so good, working great!!!

Re: Chipsounds 1.6 beta release (videos)

2012-09-10T20:13:33Z

To get 8SSP or RAW IFF files working:

Windows:
http://s3.amazonaws.com/plgshare/WIN_mod2sfz_1601.zip
extract/overwrite previous mod2sfz.exe in C:\Program Files\Plogue\Aria

Mac (ADVANCED USERS):
http://s3.amazonaws.com/plgshare/MAC_mod2sfz_1601.zip
extract/overwrite previous mod2sfz in /Library/Application Support/Plogue/Aria
(This exe needs to have proper permissions/owner, else it will fail)

Please report!

Re: Chipsounds 1.6 beta release (videos)

2012-09-10T16:04:38Z

- IFF FORM-8SSP (Protracker interchange file format). This is a
cut down version of FORM-8SVX. It stores only the mark positions
and sample data. This format does not support stereo or 16 bit
samples.

Im on it