These are not mine... they are things I found while doing various searches for Shepherd tone examples.
First example:
I think the author is using this Reaktor ensemble, from the Native Instruments user-contributed library. It starts out using tones at octave intervals, and I think the cycling is rather obvious. It becomes more convincing when he sets it to narower intervals, starting about 0:55 in.
Second example. This one uses discrete quantized intervals rather than a continuous glissando:
As you can see, the author added a note indicating that he doesn't think it turned out very well. However, I actually find it more convincing than the first example. This is despite the fact that, according to the author, it only uses two tones at a time. I think this may have to do with the chime-like tonality of the tones used; there's a lot of upper overtones and it sounds like some of the overtones are enharmonic. The addition of the drum machine track, while not necessary for demonstrating the principle, adds a nice touch and illustrates a possible use in a musical context. Unfortunately there is nothing in the author's notes about what hardware or software he used to make this.
Third example. I was utterly floored by this one:
Now obviously there's a lot more going on here than just sweeping tones up and down. The author mentions that it uses FM; I don't know if it's using the FM to do some of the tone sweeps and spreading, or just for tonality variations. He apparently did this with a Reaktor ensemble that he built himself. Note the stereo effects. In some places the illusion is very convincing; in other places cycling is somewhat obvious. It seems to hit a place at about 5:10 where the sweep can't go any further, and then at 5:58 it starts back in the other direction. Frequency shifting? The author's notes don't say.
(After you finish listening to this one, go to the author's Youtube page and check out his favorites -- rather interesting list.)
Monday, January 17, 2011
Saturday, January 15, 2011
Shepherd tones
I took a crack at making some Shepherd tones today, for a tune I'm working on. (He's trying to do trance! Run! Hide!) Shepherd tones are a form of audio illusion; they are supposed to give the impression of a tone that rises or falls forever without ever moving out of the audio range. This is often referred to as a "barber pole" effect; Shepherd tones are one mechnism for creating it. I had hunted around for some Shepherd tone samples on the Internet, and until today I had not had much luck; in most of the examples I found, either the "cycling" was obvious (it sounded like they rose/fell to a certain point and then obviously started over), or there was no sensation of moving pitch at all. I tried copying and running the example given in the Csound manual, which employs frequency shifting, but all I got out of it was phase cancellation (sounding like pulse width modulation of a square wave).
So I decided to code up my own algorithm in Csound. I chose to build the tone out of six sine waves, at intervals of an octave. Each time rises six octaves before it is faded out. I wrote the code to gradually increase the frequency exponentially, so that it is constant-time with respect to octaves (in other words, it takes the same amount of time to go from one octave to the next at low and high frequencies). Below is my code -- first, the orchestra code:
Most of this is pretty straightforward to someone with just a bit of experience with Csound. The "powoftwo()" function is a bit weird since it only takes arguments in the range -5 to +5, so a bit of finagling was needed there. The tricky bit is that the score file only plays the first tone. After it has increased in frequency one octave, it uses the "schedwhen" to create a dynamic score event that starts the next tone. The line opcode and the kruntime variable do the timing for when to kick off the next tone. There is a repetition count given in the original score event that is decremented every time a new tone kicks off, and when it decrements to zero, the code quits generating new tones, which eventually brings the whole thing to an orderly end. I originally had the test of kruntime at the end of the code block, and I found that I had timing problems -- with the arguments given, the next tone kicked off a few milliseconds either early or late, depending on what value I used for the kr rate. That created noticable beating between the tones because the intervals between them weren't exact octaves. Once I moved the kruntime test to the start of the block, the timing was dead on after that.
I had Csound render this to a file, which created two minutes' worth of audio. I then loaded it up into two channels in Metro and panned the two hard left and right. I offset the start time of the right channel. Then I ran both through the Expert Sleepers phase shifter plug-in. Then, to give them more presence, I ran them through an ambient (small room reverb) algorithm on my Lexicon MPX500 and re-recorded the result to a stereo channel. Here is a brief sample of the result.
I think the results are pretty decent. The cycling isn't too terribly obvious, once all six tones get kicked off and running. I'm going to experiment with it more Based on some Youtube videos I watched today, I'm not sure there is anything special about the octave interval (contrary to theory); I'm thinking many closely spaced tones would produce a better effect with less noticable cycling. But I'm going to use what I've got for the tune I'm working on.
So I decided to code up my own algorithm in Csound. I chose to build the tone out of six sine waves, at intervals of an octave. Each time rises six octaves before it is faded out. I wrote the code to gradually increase the frequency exponentially, so that it is constant-time with respect to octaves (in other words, it takes the same amount of time to go from one octave to the next at low and high frequencies). Below is my code -- first, the orchestra code:
sr = 44100
kr = 4410
ksmps = 10
nchnls = 1
1nstr 1
ifreq = 200 ; base freq * 2
idur = p3
iatk = p3 / 5
irel = p3 / 5
ireps = p4 - 1
kruntime init 0
; At the octave break point, start the next one
if kruntime < 1 kgoto keepgoing
schedwhen 1, 1, 0, idur, ireps
keepgoing:
; If repeat count has decremented to 0, do nothing
if p4 > 0 kgoto dontquit
turnoff
dontquit:
; Compute the exponentially rising frequency
; (necessary to make it linear with respect to half-steps per second)
ktime line 0, idur, idur
kruntime line 0, (idur/6), 1
kexp = ktime/(idur/6)-1
kpower = powoftwo(kexp)
kfreq = ifreq * kpower
;Envelope and Oscillator
kenv linen 1, iatk, idur, irel
aout oscil3 6000*kenv, kfreq, 1
; Output it
out aout
endin
And now the score file:
; Sine
f 1 0 16385 9 1 1 0
t 0 60
; inst start duration reps
i 1 0 30 20
Most of this is pretty straightforward to someone with just a bit of experience with Csound. The "powoftwo()" function is a bit weird since it only takes arguments in the range -5 to +5, so a bit of finagling was needed there. The tricky bit is that the score file only plays the first tone. After it has increased in frequency one octave, it uses the "schedwhen" to create a dynamic score event that starts the next tone. The line opcode and the kruntime variable do the timing for when to kick off the next tone. There is a repetition count given in the original score event that is decremented every time a new tone kicks off, and when it decrements to zero, the code quits generating new tones, which eventually brings the whole thing to an orderly end. I originally had the test of kruntime at the end of the code block, and I found that I had timing problems -- with the arguments given, the next tone kicked off a few milliseconds either early or late, depending on what value I used for the kr rate. That created noticable beating between the tones because the intervals between them weren't exact octaves. Once I moved the kruntime test to the start of the block, the timing was dead on after that.
I had Csound render this to a file, which created two minutes' worth of audio. I then loaded it up into two channels in Metro and panned the two hard left and right. I offset the start time of the right channel. Then I ran both through the Expert Sleepers phase shifter plug-in. Then, to give them more presence, I ran them through an ambient (small room reverb) algorithm on my Lexicon MPX500 and re-recorded the result to a stereo channel. Here is a brief sample of the result.
I think the results are pretty decent. The cycling isn't too terribly obvious, once all six tones get kicked off and running. I'm going to experiment with it more Based on some Youtube videos I watched today, I'm not sure there is anything special about the octave interval (contrary to theory); I'm thinking many closely spaced tones would produce a better effect with less noticable cycling. But I'm going to use what I've got for the tune I'm working on.
Wednesday, January 12, 2011
Sysex strings for controlling JD-800 tones
If you've spent time working with sysex on the Roland JD-800, you may have noticed that the tone layer/active buttons don't send sysex. This means, among other things, that if you are trying to turn tones on and off during a performance and record it with a sequencer, these actions will not be recorded.
There is, however, a sysex string that you can send to a JD-800 to turn tones on and off. Here is the string; it's expressed in bytes as two hexadecimal digits per byte (most software sequencers will allow you to copy and paste this into a sysex editing dialog box):
F0 41 10 3D 12 00 00 21 0x 5y F7
The x and y are variables. A byte-by-byte breakdown of the string:
[apologies for the white space problem below; I haven't been able to fix it]
There is, however, a sysex string that you can send to a JD-800 to turn tones on and off. Here is the string; it's expressed in bytes as two hexadecimal digits per byte (most software sequencers will allow you to copy and paste this into a sysex editing dialog box):
F0 41 10 3D 12 00 00 21 0x 5y F7
The x and y are variables. A byte-by-byte breakdown of the string:
- F0 The MIDI standard command byte that indicate that a sysex follows.
- 41 Roland's manufacturer ID.
- 10 The JD-800's unit number. The value "10" represents the factory default unit number of 17. If you have set your JD-800 to some other unit number, see the note at the end of this post.
- 3D The model number for the JD-800.
- 12 The command ID that tells the JD-800 to receive the following data.
- 00 00 21 The address of the tone layer parameter in the single-mode edit buffer.
- 0x is the parameter that tells the JD-800 which combination of tones should be on. The table below tells you how to set this value.
- 5y is a checksum, which the synth uses to check to see that the sysex string was transmitted correctly; if the checksum value is incorrect, the JD-800 will ignore the sysex. The table below tells you how to set this too.
[apologies for the white space problem below; I haven't been able to fix it]
Tones On | X | Y |
A | 1 | E |
A, B | 3 | C |
A, B, C | 7 | 8 |
A, B, C, D | F | 0 |
A, B, D | B | 4 |
A, C | 5 | A |
A, C, D | D | 2 |
A, D | 9 | 6 |
B | 2 | D |
B, C | 6 | 9 |
B, C, D | E | 1 |
B, D | A | 5 |
C | 4 | B |
C, D | C | 3 |
D | 8 | 7 |
Sending the string turns on and off the selected combination of tones in the currently loaded patch. It only effects the edit buffer; it's exactly the same as pushing the buttons on the panel. The changes are not saved unless you write the patch to memory.
If you've changed your JD-800's unit number, you need to change the unit code in the sysex string. The JD-800 allows its unit number to be set to any value in the range 17-32. For unit number 17, the sysex code is 10, as show above. For unit 18, the code is 11; for unit 19, the code is 12, and so on... up to unit number 26, for which the code is 19. For unit 27, the code is 1A; for unit 28, the code is 1B, and so on... up to unit number 32, for which the code is 1F.
Subscribe to:
Posts (Atom)