Summary of the mailing list till autumn 1999

Question Answer
Deutsch: Wie kann ich die beiden Versionen von Regelwerk unterscheiden (alte Version: Radiohm-Fader, neue Version: ALPS-Fader) Die Version mit den alten Fadern der Fa. Radiohm (Artikelnummer CIPGP58, Wert: 10k linear) wurde bis 1998 gebaut. Im Laufe des Jahres 1998 wurde auf ALPS-Fader umgestellt. Da die Firma Radiohm leider nicht mehr existiert, können wir diesen Fadertyp nicht mehr als Ersatzteil liefern.
Man erkennt den Unterschied an den Montagelöchern oberhalb und unterhalb der Fader an der Frontplatte. Bei der alten Version sitzen die Montagelöcher genau über/unter dem ersten und achten Fader jeder 8-fach-Fadergruppe (-> Frontplatten-Skizze alte Version). Bei der neuen Version sitzen die Montagelöcher nicht genau über/unter den Fadern, sondern etwas versetzt (-> Frontplatten-Skizze neue Version).
English: How can I distinguish between the old and new version of Regelwerk (old version: Radiohm fader, new version: ALPS fader) The version with the old faders (manufacturer: Radiohm, order no. CIPGP58, value: 10k linear) was produced until 1998. During 1998 the production has been changed to the new ALPS types. As Radiohm is no longer on the market the old type of faders is no longer available as spare parts.
The difference can be recognized at the mounting screws above and below the faders on the front panel. For the old version the mounting screws are located exactly above/below the first and last fader of each 8-fold fader group (-> front panel sketch old version). For the new version the mounting screws are located not exactly above below the faders but are a little bit displaced (-> front planel sketch new version).
Possibility to implement new features

I do not know the difficulty/possibility of implementing these improvements to the Regelwerk, however they are elements I would be very pleased to see.
Step duration displayed in 32nd, 16th, 8th , quarter, half, and

whole notes.

Track Step Time parameter displayed as 1/32, 1/16, 1/8, ¼, ½,

1/1. I do see the relative calculation in the manual, this is just

personal preference.

Midi channel and gate time settings per step.

Why can't you assign the faders to send CV outs for modulation of analog


The sequencer mode needs some improvments, here are my suggestions :

- sequencer events other than midi note - controller (0...127), pitchbend,

aftertouch mono and poly, program change

- independant run-modes for each track: forward, reverse, pendulum 1,

pendulum 2, random

- independant prescale timings for each track


Thanks for all your improvements, they are extremly welcome.

Most of the thinks are already implemented in the REGELWERK-source code, but I have to leave it out, because of the low memory.

The maximum space of the REGELWERK memory is 65535 Bytes, now (V1.3) 65004 Bytes are in use. So there isn't enough space for new features, I need the rest space for bug fixing.

For the end this year/beginning of the next year, we are planning a memory expansion and then it will be room enough for all these things.

We discuss 2 possibilities: A memory piggyback or a new 'motherboard' with more memory and maybe a faster processor, like we updated f.e. our MAQ from V2.XX to V3.XX .

I will inform you about all plans and news relating to this plans.

Actual Remark:

Since end of 1998 we ship the Regelwerk with a new motherboard. = solution 2

Relative Pitch Mode ?

I was wondering if the Regelwerk incorporated the relative pitch mode (notes are transposed according to the incoming MIDI note) used in the MAQ 16/3?

No, at the time only MAQ has this feature.

But we think about some improvements like this in the V2.X for REGELWERK.

Bug with Pulse

While playing a midi sequence and simultaneously adjusting the note

number value in the Sequencer Parameter section, my Pulse plus jumped to

program 68. Is this a known bug?

No, sorry, but I don't know the Pulse Plus so good.

This sounds as a bug of the Pulse.

Odd characters in the display

My Regelwerk is inserting some odd characters into the display. When in

fader mode, with all 24 faders named and sending sysex strings, the last

two characters of the name get changed to some odd hieroglyphs if I move

a new fader.

Ouch :-( There are some little flaws in the display refresh routines, caused by the memory problem. But this had no effect on the rest of the software, it will work correct. Refresh the display with Fader Mode or Sequ.Mode.


Refresh the display

If I press the fader select button for that fader, the name

reverts to the proper characters.

Yes, this is the big hammer which refreshes the complete display.


Naming presets ?

Also, have you incorporated naming presets yet?

No, the big problem is that the program memory is running out. I first had to made some improvements, so that I could make free some space for this code.

Actual Remark:

This will only be possible in V2.X

How to manually input SYSEX into the string

I couldn't tell how to manually input SYSEX into the string. I could however get sysex into the

string using learn/sysex mode, but that gave me more than I wanted and I could take the overflow away from the end. Dec inc works for jumpin back and forth in the sequence of the string, but the dial refuses to change the ",__,__," so how do I enter number in there?

When I try to program strings, as much as I rotate the alpha dial, the only characters that get displayed (per section of the string)are >> or .. Any thoughts?

No, but maybe you forget to define the length for the string, which in all cases must first be defined.

Any positions which lie outside this defined length are shown as either _ or 00.

For example:

If the string is going to be three bytes long :

-Scroll to position 3

-Turn the alpha dial until ' ..; ' appears. The OK LED should blink.

-Press OK. !!!!!!

-This causes you to leave the fader edit menu, and you need to re-enter to produce the correct string!

-The value that has been chosen for editing can now be scrolled to, using the </> buttons, and when it is in the 'aa' position, it can be edited using the alpha dial.

-Some bytes which aren't part of standard MIDI are reserved for internal REGELWERK functions, and are shown by the symbols '..;' or '>>'. !!!!!! (- This looks that this are the charakters you see. This could happen, if you defined a length under 3 bytes for the string. Try to define a stringlength f.e. 4 Bytes, and next time when you enter the string mask, then the positions are filled with values and then you could edit them.)

-The first MIDI data byte 'XX' is entered into the incomplete string, to set the fader value.

No powerswitch on the front

Secondly I must say that it is pretty crazy that there is no powerswitch on

the front since I intend to build the machine into my furniture and will

have to crawl under the table to get to the plug, why? That extra five buck

certainly would have been worth spending.

Our company is always concerned about the health of our customers - so we always built in an extra sport/traning-mode/feature in every of our devices ;-)

No, but we decided to use an external power supply, because of the foreign different voltages and for the safety aspects. And so we think it's the normal use, to put the power supply into a multy power socket, with a switch, so that so could power down/up your whole equipment at once. Because it's no good idea to leave the power supply always in the powerd sockect, because it's wasting so a lot of energy

This is the normal use of all our equipment. Nobody turns on/off all the units seperately.

Add new features ?

Now mind I have only been messing around with my machine for a day, but

still it seems to me that each track can only have one pattern, is it

possible to upgrade the machine to atleast be able to chain the patterns in

the machine and send them to the same output in a sequence and so to say

form a simple song like, verse, corus, verse, fill in ?

Further more, It would be really nice if the note values could be displayed

either as the value from 0-127 or as C-1, thru C#1,D-1 and so forth to C-9,

Thanks for all your improvements, they are extremly welcome.

Most of the thinks are already implemented in the REGELWERK-source code, but I have to leave it out, because of the low memory.

Now we decided for a 'new-old' motherboard with only more memory, like we updated f.e. our MAQ from V2.XX to V3.XX .

New-Old means that the 'new' board is 98% compatible with the old. But you could use greater memory devices:

The program code memory is 8 times bigger and the data memory 4 times.

But the cost's naturally rises: For the program memory 3 times and for the data memory 4 times.

How to upgrade the hardware for future releases

In that case a memory upgrade would very significant, however if I have to ship this thing back to Germany I think your local distributor had to do the update and pay for an upgrade or an entirely

new motherboard that is not good unless you guys are footing the bill.

Yes, we know this problem, but anyway the version V2.X will be an upgrade and not costfree, because the now planned version 2 improves the facilities in a great amount, which is not inlcude the now available REGELWERK V1.X - It's in some way a new device and I think it's a good policy to give all V1-customers the possibility to become a V2-customer.

I think, if you buy an other device f.e. an expander and after 1-2 years a successor of this device come out, you nromally won't have the ability to upgrade your old device. Normally you then had to sell the old, lost a lot of money and then buy the new one!!!

We think, we will make the same price for the hardware/software-upgrade like for an 'only-software' update.

If we make only a little hardware update (which maybe could be a little bit cheaper, but not really much) we could not realize all future features we want for a long time. So we think it's maybe the better way

to change the complete motherboard and recycle most of the circuits.

So, I am just getting the impression that V1.0 was a kind of "pre-REGELWERK" and the real version has a different motherboard, more memory, and can do everything it should.

However if the upgrade will be fairly inexpensive and can be done at my

not so local distributor I can certainly accept that.

No, the version V1 was so designed as it now is. But the demands are growing and you, the users, gave me a lot of good suggestions in the last months.

Now we see that REGELWERK becomes a success, what we didn't know as we put such a device on the market.

If we had used the technology of the new/greater memories only one year before, then we had to make a price more than 25% bigger, as we sold the device now. So I think it's the better way always try to make a device as low-priced as possible at the actual time. And then maybe upgrade the unit step by step, if it's time for this.

Ability to load patterns while playing

Another thing that I am finding through usage is that the ability to load patterns while playing (and sync them) would be really nice.

Yes, I agree with you. But for now our policy is that some features are reserved for the great brother of REGELWERK - SCHALTWERK!!
Upgrades: Can these be done via midi sysex?

My 2nd question is regarding upgrades: Can these be done via midi sysex? Reprogramming an ICU is not something I have the capability to do.

Sorry, not with this motherboards. We though about this feature for a the new motherboard, but then the upgrade would be much expensive, so we reject this idea, although this feature would be a great one.


What exactly is a snapshot ?

What exactly is a snapshot. How should i see if it works.

If you press snapshot, then all midievents of the current setting are sending out.

Furthermore you then could save this mididump so that you then always could recall this dump and send it out like before, although now yoy maybe have a total different setting.

Storing and loading of patterns

Although storing and loading of presets works, I cannot get it done for patterns. How exactly should this be done?

I've tested it and it works, so I think it's user operating fault and I will give you a step by step instruction.

1) You made your pattern and you want to save it under Pattern 10.

2) Press Pres/Patt Tools so long, till you see StorePreset:XXX or StorePattern:XX

3) Then you could select Pattern:010 by a) Adial or by b) PatternBank/Number switches

a) You had to increase the value by Adial till you see StorePattern:010. The Patterns came after Preset:064, then the display changes to StorePattern:001 and so on. If you turn the Adial, then you see simultanios, how the combinations of the buttons PatternBank/Number are changing.

b) Press the buttons PatterBank 1 (Fader Select 5 on the upper site) and Number 10 (Fader Select 18)

4) The OK-Button flashes - then press OK and the pattern is saved.

5) To recall the pattern press Pres/Patt Tools and now select Get Preset/Pattern

6) and then select Pattern:010 like a) or b) for Store

7) OK flashes and the press OK for getting the preset

8) then the pattern must be in the sequencer

Question Answer
Sending SysEx data of a preset

Sending SysEx data to Cakewalk seems to work (see attached file, usually

1056 bytes are transmitted, sometimes 1034).


A preset consist of one or two sysex-bulks one for the preset datas like events which must always be 1034 and maybe a second bulk with the strings which length belongs to the number and length of the strings.

I've look on to your dumfile and it seems to be correct. 2 bulks, the first is 1034 Bytes long and the second is 22 bytes, which is a empty string-bulk. If you've never made a string for a preset, then the second bulk will be totaly empty and no second bulk will be sended!

Error in display of receiving SysEx preset data

Selecting an empty preset and

sending the data back from Cakewalk does result in the messages:

ReceivePres 065

Thanks- this is a little bug, I corrected it -> V1.4
...... ReceiveChunk 001 That's o.k.
But the empty preset remains empty. What is wrong. First of all, you only could return the sysex dump to the preset number from wich you've send it out. This number is fix in the sysex-dump. But I planned to explain the sysex-format in the future so that you could change the number in the editor of your sequencer.
Thank you very much for your answers to my previous questions. I now

understand what snapshots are and how to save/reload patterns. For your

information; what I understood wrong from the manual:

1. Snapshots only contain fader data = actual values, and 2. the data get

send over as midi data (not as sysex) so they can be recorded in a sequencer

program like Cakewalk, Cubase etc.

3. A saved pattern consists of all 8 tracks. A pattern (or preset) can only

be reloaded into the pattern bank it was saved from (then it can be saved

into another bank).

Head of SysEx-Message

With respect to my remark about a sysex dump (Sending the data back from

Cakewalk does result in the messages: ReceivePres 065) your reply was: > Thanks- this is a little bug, if corrected it -> V1.4)

Since I use Cakewalk, I can edit the sysex data easily. Is it possible to

make it work properly, by a small change in the sysex data before sending the

data back to the Regelwerk? If so, what should be changed?

For Example you had this SysEx-String for editing the preset number:

F0 00 20 20 12 00 20 04 00 00 00 00 00 00 00 00 ............ F7

F0: SysEx-Command

00 20 20: Doepfer-SysEx-ID

12: Device-ID for Regelwerk & Schaltwerk

00: DeviceChannel (not used)

20: Command: Single-Dump

04: Command: Preset

00: This is the Preset Number !!!! Range 0 - 3F

It's the same for Pattern and Chunk (here are the corresponding strings and names stored for the preset), but the Command-Byte is for

Pattern: 01

Chunk: 03

Example for Pattern:

F0 00 20 20 12 00 20 01 00 00 00 00 00 00 00 00 ............ F7

Example for Chunk:

F0 00 20 20 12 00 20 03 00 00 00 00 00 00 00 00 ............ F7



Some parts in the manual are difficult to understand. Page 28 for instance, I

must have read a dozen times. A few explaining pictures in the manual would help a lot. This is what I did to try to understand the different modes.

I sent changing midi data (volume, 0-127) to Regelwerk, moved the

corresponding fader (from 127 to ca. 64 or 0 and back), and recorded the

result in different fader modes using Cakewalk5. I included the resulting

midi file as an attachment. When enlarged, both the midi data sent (see track

1) and the data transmitted/passing through Regelwerk can be recognized in

the result (track 2, 3 and 4 for immediate, relative respectively catch

action mode). In time (x-axis), the results for different fader modes were


What I expected from the Regelwerk was that it was able to:

1. Operate as a `midi thru' for note on/off commands. From the FAQ I see

there have been more comments about this.

2. Send midi data (commands and values) directly related to fader movements

(you call this normal mode, this works perfectly).

3. Change incoming midi data as programmed (change the command and/or value)

and sending out the result (and nothing else). For the midi values, this looks very much like the Velocity Multiply mode (see track 2 measure 8-14).

In fact, it would be alright if only the changed midi data itself were sent, and not the fader values (so that the volume will not jump around every time).
Is this also possible? I sure hope so.

Yes, we want to translate all this stuff, but at the moment we had great problems with our translators....

I think you only had to mute the fader, then it wouldn't send any longer any midievents, but it always uses it's datas for the Modes like VelocityMultiply....

Datas from sequencer only on Midi-Out1

To check out the tuning of some synth I hooked up my MKS50 to MIDI OUT

2(the second jack) and to my horror discovered that nothing happened. After

some fuzzing around I discovered that it sends control change and stuff

like that in fader mode, but no notes from the sequencer. If I just move

the cord to OUT 1, then it plays the notes from the sequencer right. So I

figured that it probably was a setting that either I couldn't find in the

manual or that wasn't in the english manual and made a complete hard reset,

but it remains the same, is this the way it should be?'

After several questions belonging to the midi-events generated from the sequencer f.e:

I found out, that the translator of the english manual forgot to translate this important information.

Under paragraph 6.2.2 Midi-Out-Connectors we found in the german manual:

Wichtig: 'Die Mididaten des Sequenzers können nur auf Out1 ausgegeben werden.

Realtime events werden jedoch sowohl an Out1, als auch an Out2 ausgegeben'.

which means:

Important: Only midiout 1 sends the midi-note-events generated by the sequencer. However both midi-outs are sending realtime-events.

New Alps faders used in the units built till summer 1999

Maybe some of you have seen, that we use since the last weeks Alps faders for the Regelwerk.

So many of you ask me, how they could update their old faders to the new ones.

It's only possible with very great expenditure and costs to get new


Why ? Because the new faders need other holes for the screws, as on the old


So we also had to change the whole frontpanel.

Summary: For old front panels, you had to made new holes by yourself, the

old holes then are empty -> this didn't look great.

The costs of one faderboard would be 50.00 Euro or 150.00 Euro for all three.

update kit would consist of the new frontpanel, with the boards. But this is

near all of Regelwerk, except the base board and the ground case. The price

for this is nearly the price for a new Regelwerk.

So we decided not to offer an official update kit.