Saga Musix' Demoszene-Blog.
In diesem auf Englisch gehaltenen "Blog" möchte ich Musik, Demos und ähnliches sammeln und teilen.
Wenn du möchtest, kannst du den Blog abonnieren.
Seite:  2 3 [Nächste]
I've been building my studio with lots of vintage synthesizers for more than ten years now.
There are some common faults this old hardware develops with age, many of which are easy to fix with basic electronics knowledge and basic soldering skills.
Often these repairs require purchasing spare parts, which can be rather expensive when bought from stores specialized in vintage synthesizers.
Of course I know that they need to make a living, too, and sourcing the parts, figuring out what are the correct and best parts to sell can be a time-consuming process.
If you want to be 100% sure that the parts you buy will fit your synthesizer, buy from these stores.
Otherwise, here is an assorted list of spare parts I bought over the years that can serve as cheap and suitable replacements.
Let's get the most important thing out of the way: Service manuals! Many can be found easily through your favourite search engine. archive.org and ElektroTanya have a huge collection, too. I recommend looking there first.
Ah, the bane of every synth owner's life. One of the most common parts to break on synthesizers.
You know it's time to replace them when a soft touch is not enough to trigger the buttons anymore.
Better replace all of them in one go, as more and more of them will fail over time and they are really cheap.
Without further ado, here are compatible tactile switches that I have bought over the years:
- Roland D-50, Roland PG-1000, Kawai K4: TE Connectivity ALCOSWITCH 1825910-6
- Roland JD-800: You can get a set of buttons for a fair price at Vintage Synth Parts. The JD-800 uses three different types of switches. The third type, used for LFOs, filter mode and other patch settings is not part of this set, though.
- Roland R-8: Omron Electronics B3F-6120. They are a bit on the expensive side compared to the previous items. I have a feeling that the switches used in the D-50 might also work here, given that there are extra holes in the PCB for switches with four legs, but maybe the missing ground pin would cause issues.
- Roland JP-8000: TE Connectivity ALCOSWITCH FSM4JRT (untested, will most likely work. again the switches used in the D-50 might also work here if the PCB has holes for switches with four feet, which I have yet to verify.)
- Kurzweil K2500: TE Connectivity ALCOSWITCH 1825966-1
- Behringer BCR2000: TE Connectivity ALCOSWITCH 1825967-1 (I assume that the BCF2000 uses the same type of switches)
Roland's SR-JV expansions ROM cards are known to contain a capacitor that may leak or even explode with age.
There are many suitable replacements with higher margins than the original capacitors Roland put on those boards. I used Nichicon GYB1E101MCQ1GS as a replacement.
Electroluminescent display backlights get dim with age. Typically your options are to replace the EL foil to revive the original, or to replace the entire display assembly with a new LED or OLED display.
This also has the advantage that it avoids the high-pitched noise that you can often hear from the EL display's inverter, at the expense of modifying the look of the synthesizer.
Finding a suitable replacement display can also be a tricky task at times. Displays advertised by their seller to work with a specific kind of synthesizer are often overpriced.
For my Yamaha TG77, I opted to replace the entire display assembly with an LED-backlit display that is guaranteed to work with the synthesizer.
Yes, it's probably four times more expensive than finding the same display on eBay (okay, maybe twice as expensive after customs duty and shipping), but I think the price is still fair and it comes pre-assembled with clear instructions and no soldering is necessary, which saves some work.
The display is available in various colour schemes, the one linked above is probably the closest to the original colour scheme of the synthesizer.
The "alpha wheel" on my Kurzweil K2500 broke down, no longer producing a nice reassuring click with each turn, spinning freely instead.
I could not find a drop-in replacement, but the Grayhill 25LB15-Q encoder gets close.
The shaft is too long and a bit too thick, which can be fixed by cutting it a bit shorter and using sandpaper and a file to make it a bit thinner.
Make sure to keep the "D" profile of the shaft so that it slides nicely into the hole inside the button.
When doing so, constantly keep checking if the shaft fits into the button so that you don't make it too thin - otherwise the button will not sit firmly on the shaft anymore.
The little hole in the lower plastic part of the alpha wheel is also not quite in the correct position for the little stud of the encoder, but that hole can be widened a little bit with a sharp knive or scalpel so that it fits.
This replacement is a bit more "clicky" than the original part and thus requires slightly more force to use.
Ah, my speciality, you could say! Together with my pal dojoe, we built and sold Roland memory card replacements (M-128 / M-256 / M-512) that are backed by non-volatile MRAM.
Unfortunately we no longer sell them, but you can build your own, as the card design is open-source.
Looking for Ensoniq or Kawai memory cards? They are even rarer and even more expensive than the Roland cards.
The good news: These cards are just rebranded Fujisoku 38-pin SRAM cards, and sometimes you can find those OEM cards for much lower prices (and by that I mean less than 30 Euros).
Just make sure it has the right capacity - a card type starting with BS8 indicates 8KB of SRAM for example, equivalent to a Kawai DC8, and a BS64D1-B card would big enough to be compatible with any Ensoniq or Kawai synthesizer.
Some sellers refer to these cards by their US patent number ("uspat4780791"), as this is usually the only thing printed on those cards apart from the brand name and serial number.
German users may also have some luck by keeping an eye on "Telekom Connex Memory Cards", which are also just rebranded Fujisoku cards.
Don't pay outrageous prices for the Kurzweil K2500 PRAM option. Build a cheaper one yourself: dojoe got you covered, again.
Speaking of the Kurzweil K2500 (and the K2000): Revision A-J of the K2500 (and all K2000s) use 30-pin SIMMs for sample RAM. If you want to max it out, you need to go with 16MB modules, which can be expensive to find.
Some years ago I found this kit on Amazon, which was comparably cheap at the time (less than 30 USD), but it has since gone up in price. Still, it is probably one of the cheapest brand-new options that you can find.
Owners of the later K2500 models are lucky as they take 72-pin SIMMs, which are much easier to find in the required capacities.
Want to burn your own synthesizer ROMs? Have a look at the Synthesizer ROM archive!
Software / Patches
Ensoniq sadly is one of the few once-big synthesizer manufacturers that are no longer in business. This means that a lot of great resources were lost in time.
However, the Web Archive snapshots of their download pages are pretty complete, so a lot of the orginal material such as demo song SysEx dumps for the SQ series can be downloaded from there.
A lot of older Kurzweil material is still downloadable from their website, so don't get scammed by people selling original Kurzweil floppies for your K2500 for outrageous prices - you can still download various operating system versions from the Kurzweil website.
The contents of their old FTP are currently unavailable, which might be a temporary issue, but even if it's permanent, they can be downloaded through a Web Archive snapshot.
I recently got my hands on a Yamaha DMP7 (their first digital mixer), and apart from a completely depleted soldered-in backup battery that I replaced with a CR2032 battery holder, the motorized faders were barely working.
Obviously this was due to worn-out rubber belts. I couldn't find any resources on the correct size of belts, which is really unfortunate: As cassette players and optical drives have somehow went out of fashion for some reason, replacement belts for these kind of devices are often expensive.
Either you pay multiple Euros for a single belt of the correct size, or you end up buying a hundred belts for 10 to 20 Euros, but there's only one or two belts of the required size, so the final outcome is still expensive.
Most of those kits lack the small belts required for this repair, anyway.
Luckily I found that German electronics shop Pollin had a selection of belts that could potentially fit, with a convenient price break point at 10 belts - and the DMP7 requires 11 belts.
The belts that I linked have an approximate diameter of 18mm, or 30mm when stretched. I think this might be a bit too tight, but the next bigger option (22mm / 35mm) is definitely too lose. If you have the possibility, you should try to source belts inbetween those two measurements.
Assorted repair resources
Untested / planned fixes
The Yamaha AN1x display backlight can get dim with age (although I do not remember it ever being brighter than it is now...). The backlight consists of 2V LEDs, which narrows down the options a bit. Some replacements are discussed on the Syntaur forums.
My Roland PG-1000's backlight is still okay, but it has some annoying high-pitched noise coming from the display itself. Since the original display looks absolutely gorgeous, I'd like to keep it stock if possible. I will need to figure out if replacing the EL foil or other parts of the display can fix the issue, and will update this blog post accordingly.
I also want to replace the slider dust covers in various synthesizers, as the foam used in those covers started to disintegrate or already has done so. Stay tuned.
That's all for now. I will add more material in the future when I need to do further repairs.
Last updated: 23rd of May 2023
» 2 Kommentare
In an earlier blog post, I wrote about Sidewinder's music. Much to my delight, I found out a while ago that many classic Sidewinder modules have been remastered for his Timeless album, and they really sound fantastic. Exactly how I want a modern remake of classic MODs to sound. Go grab it!
» Kommentar verfassen
Most people would probably expect that there's nothing left to discover in the most widespread legacy module formats in 2021.
And yet, sometimes little details are discovered that were apparently overlooked by everyone else so far, or simply noone cared about them.
This is exactly what happened not too long ago when I dug around in some S3M files, and while it is of course very well possible that someone else has made the same discoveries as I have made here, I am not aware of anyone documenting them before, so here we go because this was quite an epiphany worth talking about!
For many years I have been aware that there are some small but sometimes significant differences between Gravis Ultrasound (GUS) and SoundBlaster (SB) playback in Scream Tracker 3. For example, sample swapping works with the SB driver but not the GUS driver.
This is annoying, because there's not one objectively correct way to implement an S3M player, and a few S3Ms rely on either GUS or SB playback style. For a long while I have thought how one could heuristically detect how an S3M file should be played (something that OpenMPT already does with MOD files), but I couldn't come up with any convincing heuristics.
Scanning sample texts? Too fragile. Looking for panning commands? Nice idea in theory, but there are many songs written for external players which supported panning regardless of which sound card was used.
Interlude: Many oldskool trackers simply dumped their internal data structures into their file formats. This is the reason why sometimes seemingly unnecessary data fields can be found in those files. Often these can be used to fingerprint whether a file was made with the original tracker that introduced the format or a clone, because the latter would typically zero out those fields, while the original tracker might keep some random data from runtime in them (e.g. EMS handles or whatever).
For most formats this kind of fingerprinting is not necessary, but for once, this turned out to be useful.
So, a while ago in June 2021, 8bitbubsy and I were talking about Skaven's "maxtestsong", a Scream Tracker module using 32 sample channels. Scream Tracker 3 itself could only use 16 sample channels simultaneously, so the file must have been created with a custom internal Scream Tracker build that could handle more sample channels.
This lead us to talking about "Call Me An Angel (Iri Mix)", another S3M module using 32 sample channels, but using a different channel allocation table - in "maxtestsong", the extra 16 channels were turned off according to the file header, while "Call Me An Angel" essentially instructs the player to re-use the same physical sample channels that were already used for the first 16 channels, which may produce interesting results when played back in Scream Tracker. OpenMPT detected this file as being written in Scream Tracker 3 rather than a known third-party tracker. So just to be sure, I re-saved the file in Scream Tracker 3 - if the re-saved file was 100% identical to the original file, it was unlikely that another tool was used to create this track.
But... the new file wasn't identical. There were some tiny differences in the sample headers, which turned out to be in the "Int:Gp" field - the internal address of the sample in GUS memory, which is of course useless to store in the file, but it turned out to be a goldmine.
I quickly figured out that Scream Tracker 3 cleanly initializes the "Int:Gp" values to 0 for empty sample slots and 1 for normal samples when using the SB driver, while the values would differ between samples when using the GUS driver. Yes, this was it! It was possible to reliably tell if the file was last saved with the GUS or SB driver loaded, and it should be a fairly safe assumption that the last driver used while saving the file is also the driver that is intended to be used for playing the file. If Scream Tracker didn't clean this field when re-saving a previously GUS-saved file with the SB driver, this discovery might have been useless.
After figuring this out, there were some remaining questions to answer - would this work for all Scream Tracker versions? Early Scream Tracker 3.00 versions only supported SoundBlaster output, and those versions always wrote 0 into the "Int:Gp" field. But at some point in late 1992, GUS support was added, and all Scream Tracker versions since then populate the "Int:Gp" field in a way that could be easily fingerprinted.
I guess I'm incredibly lucky that I use the GUS driver by default in my Scream Tracker DOSBox setup (a relic from more than ten years ago when I was running DOSBox on a much slower CPU), because otherwise I might have never turned a closer look at the "Int:Gp field" - "Call Me An Angel" was saved with the SB driver, and that's the only reason I saw those differences in the file.
Soon after, I made another discovery that might explain a long-standing mystery that I have been wondering about for many years. In "Who is the real Timelord?", I mentioned that there were some S3M files with IRC chat logs at the end of the sample data. There are also many S3Ms with other seemingly random crap past the sample loop end.
I always wondered how this could happen - did Scream Tracker not read those sample files correctly from disk and accidentally read some cluster from an unrelated file? It must have been a Scream Tracker thing, because this phenomenon is incredibly common in S3M files while being practically non-existent in other module formats.
It turned out that the answer to this is also in the sample header fields. For the SB driver, there is some sample loop unrolling code in Scream Tracker that doesn't quite do the right thing. Supposedly Scream Tracker tried to put the first 512 samples of the sample loop past its loop end, and for some reason the offset to write those samples to is stored in the "Int:512" sample header field.
However, what Scream Tracker ends up doing is moving a block of sample data 512 bytes closer to the sample loop end (which is stored in "Int:512"), but this block extends 512 bytes past the actual sample end - and this means that whatever 512 bytes were following the sample end would now become part of the sample. Often this would turn out to be some other sample data - or just random bytes left over in memory from some other application that was previously running (remember, no memory protection in the DOS days!). So if you re-save a file in Scream Tracker where the "Int:512" field of some sample is set, you will trash that sample's last 512 bytes with some more or less random memory. With this knowledge it is now also obvious why so many samples in S3M files seem to have their loop end perfectly matched up against some follow-up garbage - the garbage wasn't there when the loop was initially created.
Alright, that's it for now. I haven't written a blog post in a long while, but I thought that this topic was worth taking about in more than just some dry developer documentation.
» 3 Kommentare
The Roland D-50 is an amazing synthesizer, but its keyboard circuitry also has some small issues that may show up after all those years.
To detect the key velocity, there is a pair of electrical contacts below each key. Due to their arrangement, the time between closing the two contacts varies depending on how hard you hit the key. The contacts are protected by rubber caps, but small dust particles (or as my case when I got my D-50 five years ago, a piece of tin foil ) may get below the caps and prevent the circuits from closing. Depending on which contact the dust ends up on, the key no longer sounds at all (I have never experienced this), or it always sounds at full velocity (like in my case). It is also possible that this only happens randomly and not every time the key is pressed.
Luckily, it is possible to fix this issue by cleaning the circuit boards. There are various tutorials on the internet which helped me fixing the problem. However, some of these tutorials contain unnecessary steps or otherwise contradict each other, so I decided to share my experience with the procedure here. Still, you may read the other tutorial and watch the video to get a more complete idea of what you need to do. Read the whole tutorial first before doing anything!
Step 1: Opening the device
To open the D-50, it has to be put on its top. Mount it on some books or similar boxes to avoid resting the synth on the joystick and pitch bender. Remove the five screws on the back of the device and the screws on the bottom of the synth. You do not need to remove the four feet.
Step 2: Removing circuit boards
Once the synth is open, it's time to get the main board and key scan board out of the way. The main board is the big circuit board that sits in the middle of the synth. I decided to not unmount the board entirely, since I am not a masochist and do not want to disconnect all the connectors on the mainboard and ruin my fingers. I also wanted to cut a minimal amount of cable ties. I ended up cutting the two cable ties that hold the shielded cable at the bottom, as that will also help removing the key scan circuit board entirely. After that, I started disconnecting connectors on the mainboard until I could swing it away to the back of the synth.
Technically, you probably only need to unmount the key scan circuit board if you want to fix any keys below it, but I still recommend unmounting the board and keep it safe. To do this, you need to disconnect some more connectors below the board.
Once this is done, you can remove the six screws the hold the keyboard assembly in place. Have a look at the other tutorial if you are unsure where the screws are located. Also disconnect the aftertouch ribbon cable at the right end of the keyboard assembly from the board. Now you should be able to move the keyboard assembly out of the synthesizer. Be careful when doing so.
Step 3: Fixing the keyboard
To remove the keys, you first need to remove the springs that hold them in place. Note that black and white keys use springs of different length, so keep them separate! The springs for white keys have fewer coils than the springs for black keys. You will need to remove a number of keys next to the faulty key - how many pretty much depends on the length of the rubber strip below the keys, which varies across the keyboard. If you are unable to find the ends of the rubber strip, just remove more keys.
After the springs are gone, you may have to loosen the plastic film strip that holds the keys in place on the back of the keyboard assembly. You can pry it open carefully with a screwdriver. You can then remove the keys by pushing them below the film strip, but note that black keys cannot be pushed out before surrounding white keys are gone.
Now that the keys are gone, gently put the paper strips below them to the side (e.g. by fixating them with a screwdriver). Below them, you can find the rubber strips which need to be removed gently. Make note of how exactly the rubber strips were inserted (both vertical orientation and the horizontal "offset" is important!). Once those are gone as well, you can clean the contacts on the circuit board using rubbing alcohol (preferrably 90% or more) which you put on a q-tip. Be sure to clean the surroundings and the rubber caps from any debris as well - you do not want to repeat this procedure again too soon, do you?
Step 4: Putting everything back in place
Let the board dry a bit and put the rubber strips back in place. If they do not seem to fit at first, you possibly rotated them accidentally. Turn them by 180° and try again.
Remember to put the black keys back first, then the surrounding white keys. Now you can put the springs back on the keys, and make sure the film strips on the back sit firmly again. If it no longer glues to the board afterwards, some tape or glue may help with keeping them in place.
Now you can mount the keyboard assembly again, reinstall the screws and connect the aftertouch ribbon. Reconnect the key scan board and install the screws. Do the same with the main board, and put some new cable ties on the shielded cable. Close the unit, put the screws back in place and you're done!
» Kommentar verfassen
People like talking bad about ModPlug's IT/XM format hacks, and quite often they are of course right - ModPlug shouldn't extend these formats to add features that will either crash the original program or that simply make the file sound completely different. But is this true for all new features?
I wouldn't say so. One feature where I feel that quite the opposite is true are, surprise, instrument plugins (VSTi)! Why would I say that, given that VSTs are probably the most criticized feature addition? Especially VST instruments, which stay completely silent when played in any other player? Well, that's because those other players simply don't implement one of the most interesting features of Impulse Tracker and Fasttracker 2: MIDI output.
Let me give you an example. Do you hear anything apart from a drum beat when playing this with your favourite IT player? No? You don't hear an organ? Well, sorry to disappoint you, but that's not ModPlug's fault. This file was saved in Impulse Tracker. It plays correctly on Interwave and AWE soundcards, since those are the only two drivers in IT that can have sample playback and MIDI output at the same time. Instrument plugins are just a layer on top of this MIDI mechanism, and instead of having to tell people which synth they have to hook their computer up to, you can simply store a reference to a softsynth and all its parameters in the module file, making this awesome feature of IT and FT2 way more portable. If you compose a song with VST instruments in OpenMPT, you can, in theory, load it into IT, use one of the two MIDI drivers and play it there as well! The additional information that's required to store the VST references won't interfere with IT or FT2, so it's no problem really.
I do agree, though, that effect plugins are slightly more critical than instrument plugins, but keep in mind that there's worse - like IT's AWE32 driver which could enable hardware reverb and chorus, but the settings for those two effects were actually not stored in your IT files. This is just like adding a chorus or reverb plugin to your song, except that with plugins, you can also store the exact settings. I do not necessarily think that it's a good idea to spread such IT files with embedded plugin settings, but the same is of course true about IT files written in Impulse Tracker that make use of AWE32 effects or IT files that make use of Impulse Tracker's MIDI output. And the same holds for XMs, of course.
» 1 Kommentar
Some of you may remember the story about A Scam Artist called Jay, a person that ripped of several well known modules by various tracker artists and sold them as his own on his band's CD. I'm not aware of many cases where people claimed to have written some tracked music that wasn't theirs, but recently The Mod Archive was contacted by two persons claiming to own the music released under the handle Timelord. Well, I was curious to find out who of the two was the real artist... So I did some research and wrote a story about it. Have fun reading it!
» Kommentar verfassen
Some of you might be using my program Mod Library for performing searches on their module collection. It works great for finding sample texts and similar things. However, what do you do if you don't want to know which module contains a certain sample text, but rather which module contains a certain melody? I often have melodies playing in my head, most of the time I even know that they are from a module, and typically I even know the module format and the rough time frame in which it was written (most often this would be an XM module written around 1997, but that's a different story ).
Wouldn't it be cool to have a program which would let you search for exactly this kind of stuff? It certainly would. And would it actually be doable? Yes, it would! And who would do it? Well, maybe I would! I am currently thinking about completely rewriting Mod Library. The new version might replace the BASS library (which is great for what Mod Library currently can do, but sadly not for what the new version should be able to do) with the OpenMPT core for loading modules and analysing their patterns. The note information from the patterns would then be stored in a database using relative offsets (so that it doesn't matter if a tune was written in A minor or D minor). I find this idea very intriguing, but I can make absolutely no estimates if / when I will be able to code this. Is anyone else actually interested in such a project?
Update: In May 2014, development has finally started!
» Kommentar verfassen
Hoffman of Unstable Label has released an awesome jungle musicdisk called 8-Bit Jungle at the Sunrise Demoparty last weekend. Although it's not entirely new material, you can safely say that this is one of the best music disks for the Amiga for some time. The download includes Amiga diskette images as well as the original Protracker MOD files as well as MP3 renders. Download and enjoy!
» Kommentar verfassen
Finally, The Sound of SceneSat Volume 2 musicdisk is available in high quality Ogg Vorbis and FLAC! This epic collection of 73 fine tunes is nothing less than awesome.
» Kommentar verfassen
Yersterday, I've come across some music by Maxus, and I was instantly captivated. On his website, you can find some really excellent chillout and psytrance music, all made with MadTracker. Some tracks I am especially fond of are:
If you like this, you will probably like other compilations by New Age Beats as well. "Andromeda" is for example included on M-Ether 2.
» 2 Kommentare
Seite:  2 3 [Nächste]