Andrew, there were comments going into the feature request that were really a bit wide of what supposed to be going on there but it is all relevant discussion:
1. Well, no, I'm not planning rendering SID files under bristol, but I think it'd be cool a cool emulation under bristol
Agree here completely, it is a very interesting development and I will try and keep the design as close to a SID chip as possible.
2. Also, scratch that rather stupid idea of the two arpeggiator modes. It's quite stupid sounding and probably a lot more meaningless work for you.... But I'd say that an arpeggiator that can go to quite fast would be cool. (or at least faster than currently. :P)w.
It may actually work quite well in multiple arpeggiator modes. It can have its own arpeggiator which would be required for some of the rate of change of notes, I don't see why it cannot also be piggybacked off of the existing arpeggiator code used by the Roland, Oberheim emulators and the bassmaker discussed belo
3. But also, you mentioned the Bristol Bassmaker, are you implying that the various bristol synths can/will hook up to the Bassmaker and be able to be sequenced from the bassmaker?
The bassmaker will not have an engine component, it is simply a GUI that can send messages to the engine on whatever midi channel. That way you can start the BassMaker with any synth and sequence it. The sequences are going to be monophonic and the sequencing speed will not be as fast as the SID chip might want.
4. Say that, as you said, you've got the equivalent of 3 synths with their own waveforms and envelopes right? Maybe, when designing the emulation you could well, place the 3 synths onto 3 seperate channels, but have their parameters editable from one Brighton GUI?
Yeah, I was considering that kind of stuff too, did you ever see the monster Oberheim 4 and Oberheim 8 systems? They were just like that, one keyboard with 4 monosynths each programmed separately. Not sure if I want to do one though. The later analogue polysynths were one keyboard, 'n' synths (4, 5, 8, 10) all driven with just one set of controls so that each voice produced the same sound and bristol uses that model. Several of the emulations are two synths on two separate channels with two separate set of controls - the b3, prophet-10, obx-a, jupiter-8, vox-m2 all use two polyphonic emulations.
Kind regards, Nick
1. The bassmaker will not have an engine component, it is simply a GUI that can send messages to the engine on whatever midi channel. That way you can start the BassMaker with any synth and sequence it. The sequences are going to be monophonic and the sequencing speed will not be as fast as the SID chip might want.
Just out of interest, what sequence speeds are we talking about? is it measured in BPM?
2. It may actually work quite well in multiple arpeggiator modes. It can have its own arpeggiator which would be required for some of the rate of change of notes, I don't see why it cannot also be piggybacked off of the existing arpeggiator code used by the Roland, Oberheim emulators and the bassmaker discussed belo
Yeah, I agree that it'd be better to reuse the existing arpeggiator code, than coding a new one.
1. To start with this is not going to be measured in BPM. It will be measured by your ear! Eventually it may support BPM and MTC (Midi Time Code) to allow it to drive or be driven by another device however that it not my initial concern: first I need to see if people want to use it, then consider how to make it more useful. There are a lot of sequencers out there, this is just going to be another one.
2. I am going to write another arpeggiator just for this. The SID emulator will be a black-box so driving it will be a new interface for the emulator. What I mean by black-box is that I intend to literally emulate the chip as a unit so will need to put together some interfacing code to link it into the existing emulators. That makes it interesting which is the main drive behind bristol.
So the chip will be a black box, but you'll have another brighton window open that the user can use to program the "chip"?
Yeah, there will be a brighton GUI that will direct the engine on what chip registers to write to control the audio that it generates. There might end up being a few different GUI depending on how the chip gets used. I think on the C64 there were a few different apps using the chip, some synths, some sequencers so we will have to see how that develops. I will deliver at least one reasonable GUI that will drive one chip to get three voices and we will take it from there.
I have started working on some of the chip basics, on the register addressing, parameters, internal variables and the first bit of code required - to reset the chip to a known state. Amazingly interesting idea for a project.
Sorry, sometimes I can be a bit slow. When you mentioned one GUI with three voices integrated I only just realised what you meant. Yes, this is very possible and will probably be the model. Each SID voice is an oscillator and an envelope generator with a bit of routing, fairly simple, and these all drive into the same single filter so it should be in a single page in the GUI along with switches to select some options.
Heh, cool. :-)
So are you actually going to emulate the various address registers and variables and stuff? That does sound pretty cool.
I'm waiting with bated breath for 0.03.9, I can't wait to play with the bassmaker. :-) But don't allow me or anyone else to rush you until you're ready to release! Keep up the great work Nick!
The actual 6581 SID chip emulation is finished, feature set has been
checked however full functionality can only be tested when this is part of
a full synth emulator. That work is well underway, it will use two SID
chips, one will generate audio with three voices which was the starting
point, and then an LFO and Envelope were needed for modulation of the
voices. It was decided the best path would be to extract these from a
second chip as it leads to some interesting setups and has options for
emulating 5 rather than three voices quite easily - only voice-3 from the
second chip is required for the mods leaving two for general use later.
There are a couple of other choices for alternative configurations such as
using the two IC for splits and layers with different mod capabilities and
another option would be to make a 5 voice synth where each voice is
emulated by SID chips.
The key assignments modes for the first emulator will be monophonic,
Poly-1 where all three voices sound the same, poly-2 where each voice has
its own sounds, and Poly-3 where each has its own sound however all voices
above two are sounded with high speed arpeggiation on the third voice,
similar to the C64 sequences. These can be adapted depending on results but
seems like a good starting point. Arpeggiation rate will be from 16 samples
up to 250ms however that may also change depending on requirements.
Ok, the SID chips emulator is a 3 voice synth now? Compared to a one voice synth copied 3 times?
Also, It'd be kinda interesting to emulate 5 voices. :-P
Hmmm, or is "one voice synth copied 3 times" what you mean by the Poly-2 key assignment?
Are you planning on being able to switch between the 3 modes on the fly?
The SID chip had three voices. Each voice had:
1 oscillator to generate 3 waveforms and noise
1 envelope generator
sync/ringmod to other voices
After that all voices could be either sent to the filter or sent directly to the output. All the C64 songs used one of these chips so only had access to three voices and the chip emulator does just the same. The first synth that bristol will use with this SID 'chips' will use just one to generate sounds, hence it will only have three voices and one filter. There will be an additional ADSR and LFO. These come from a second SID however that is by the by, ie, the first emulator will not give access to more features from the second instance of the chip.
Poly modes: these can all change, they are just ideas.
Mono is all voices on the same note and a phat mono synth.
Poly-1 will have all three voices generate the same sound by allow you to play any chords you want. You can see all three voices in the GUI but the sound will only come from the GUI settings of voice-1.
Poly-2 will be able to configure each voice independently, and the filter. Each midi note can sound different.
Poly-3 will be Poly-2 but with added arpeggiator so if you play more than three notes then the extra ones will be put in the arpeggiator queue.
I am not sure how poly-3 will sound - if it does not work well we can work on another specification afterwards. Also, doing 5 or more voices is something that will come afterwards too.
kind regards, Nick.
Hm, so what you're saying the SID emulation will have 2 modes? a phat mono mode and then a polyphonic mode?
I think I might be understanding what you're saying about the ideas of the poly modes..
Say, for example, if you have have poly-1 on, wouldn't it be closer to an actual SID chip to have voice-1 on midi Channel 1, voice-2 on midi Channel 2 etc? Thereby sort of emulating the sort of 1 voice per channel, the way that C64 Sequencers would make sequences? I.E You'd have to modes on the emulation, the Phat mono mode with all three voices played together and then a 'fake' polyphonic mode with each voice on seperate channels, but still monophonic per channel?
Mono mode and Poly-1 are fthe
Oops, that submitted a bit quickly.
Mono and Poly-1 are definately for a single midi channel. Poly-1 is how a typical polysynth would work.
I agree with you completely that mode Poly-2 and Poly-3 would be interesting with multiple midi channels, it would let a sequencer control each of the voices independently however at the moment a bristol synth will either respond to one channel, or can be in OMNI mode and will respond to all of them by ignoring the channel.
Neither of these modes are quite what you are asking for in poly-1 or -2 and I will have to leave them for future study: I can make an exception but without knowing what works well and what doesn´t it might be better to see how the first release works and change it after that. The honest truth is that the arpeggiation itself may define what the best modes are and that has not been done yet.
Well, (and this is just my idea) it wouldn't be easier to just create a 3 channel 1 voice per channel synth like with the Hammond and (with two manuals) the pro52? Also to join the 3 synths together, wouldn't it be easier to enhance the dual code from the pro52?
Though thinking about that, from a 3 channel synth point of view that way you'd end up with a phat mono, rather than a polysynth..
This is turning out to be rather complicated...
Also, what have you got in mind for the arpeggiation?
The existing dual manual synths actually use two emulations at the same time. As far as the engine is concerned it is running two synths separately on different (and sometimes the same) MIDI channel, the GUI ties them together. Each synth only accepts one MIDI channel at a time though.
This is a very different model to having one synth accept multiple channels. It can be done but I would need some changes to the midi management code and I don't really want to do that unless its a pretty good emulator, will see how it turns out.
The arpeggiator will take one of the voices and reprogram the voice frequency every fixed number of samples. The low end will start with a change every 16 samples up to about 10 thousand. The frequency values that get set will depend on the keys you have pressed - arpeggiation.
"The existing dual manual synths actually use two emulations at the same time. As far as the engine is concerned it is running two synths separately on different (and sometimes the same) MIDI channel, the GUI ties them together. Each synth only accepts one MIDI channel at a time though.
This is a very different model to having one synth accept multiple channels. It can be done but I would need some changes to the midi management code and I don't really want to do that unless its a pretty good emulator, will see how it turns out. "
Yeah, my apologies, that's what I meant (running 3 monophonic synths and tying them via a GUI), but now that you think about it, you're right, the arpeggiation would affect wether that's possible.
Also, I think we appear to have different design concepts about it.
I will have to take your lead on some of the options here as I think your ideas probably make a lot of sense. At the same time I need to have a base design from which we can work so let me get this first emulator out and after that we can work on changes to make it more useful. Once the chip generates some interesting sounds, ie, it works, then we can make it more useful.
You can find a screenshot of the partially finished GUI on the website now. The silkscreen text is not finished but I thought I would post it already, the development hit a little snag after my disk crashed. Managed to salvage pretty much everything but it has taken a while to get back on track.
I like the look of the SIDney! :-)
I'm slightly giggling to myself... you may be able to use Noise with the LFO? Interesting idea. :-) I'm loving the 'vintage' wood panel.
I agree that you should get the first version of the emulator out and then use that as a base for additional work.
As for my '3 mono synth channels controlled from 2 GUIs' idea, while it probably might be more closer to a SID chip from a sequencer point of view (though maybe this isn't feasible due to Bristol's MIDI management library, or you're not thinking in that sort of way.), it's entirely up to you whether or not you'd implement it all. It may not even be a particularly good idea.
But I agree that we (and anyone else reading this.) should discuss if any changes need to/should be made to the SIDney emulation.
Thanks for your time,
Noise with the LFO is an interesting one, it goes like this: noise generates random samples. Every now and then, a period typically defined by the LFO, one sample is taken and held for one LFO cycle - its called Sample and Hold. That value can be selectively applied to other parameters and introduced some very nice effects. Joe Walsh used quite a bit of it from his old moogs and you can here it in the Explorer and Voyager synths, in the ARP odyssey and with suitable patching in the ARP 2600 emulation (and others).
Now only having one output from the LFO is an issue so I will probably have to sample the noise signal using the arpeggiator clock.
Yes, the paneling is groovy, no? All very good fun, and an interesting project to work on.
Cool, It should be fun to play with then. :-)
Just wondering, when coding a new synth, which do you start with first? The GUI front-end or the back-end?
Quite a lot of the time it is the GUI that comes first - there is little point putting together an emulator unless it can be tested and that requires the GUI to configure its settings. Consequently the GUI goes together, then slowly the audio back end where each parameter in turn is linked up and tested.
There are occasional exceptions where some DSP code leads the way. The SID was admittedly different - I did the chip emulator first as it got my attention but then it was all standalone code - the chip works independently with its own interface so I wrote a small piece of interface driver code (sidtest) to allow me to test it with raw IO and used this to debug the implementation of the chip.
Just wondering, in the mod section of the sidney (and I know the picture on the site may be changed between now and whenever it's released) you have an ADSRG section? What are you planning on having the ADSR for? Also what does the G stand for?
This is a modulation envelope, the G stands for gain, or depth. It can be used for all the same mods as the LFO but sounds different - I put it on there to find out more about the chip - it had an analogue output for sound and a few digital outputs - Osc3 and Env3, so I decided to use them for mods by making Osc3 into an LFO. A typical use would be to send the Env to the filter cutoff. With the LFO this sounds, as you know, like wah-wah. The Env would give a more typical filter sweep. You can also send this ADSR to the PW for some nice effects and to the oscillator frequency. The latter is a bit too much like 'special effects' unless it is applied at very, very low level. These mods all work now, fixed the code over the weekend.
One thing that struck me is that there is no touch sensitivity. Not much I can do about that however a future release could add mod options such as depth tracking velocity or channel pressure. The effects depth can be controlled already from the mod wheel so adding velocity tracking would not be a lot more work.
These mods all work now, fixed the code over the weekend.
Could you send me the (unfinished/untested) code in development? It'd be fascinating to see how you did it! Sending messages from the GUI to a backend interface which 'programs' the chip. Sounds really cool!
"One thing that struck me is that there is no touch sensitivity. Not much I can do about that however a future release could add mod options such as depth tracking velocity or channel pressure. The effects depth can be controlled already from the mod wheel so adding velocity tracking would not be a lot more work."
so does "depth tracking velocity" mean that you could have the depth of mods controlled by how hard/soft you hit the keys and does channel pressure mean after touch?
'Depth tracking velocity" would be just that - the harder you play your touch sensitive keyboard the more depth of mod you can apply. It will have to go in a future release since it also needs controls to suit playing styles. It could be made to work with Velocity or after-touch. This can be either channel pressure but also 'poly-pressure' if your keyboard supports it - you can then 'express' individual notes from the keyboard.
These 'Poly-Pressure' keyboards tend to be both expensive and heavy, and some of them are not really that expressive. I have an Ensoniq ASR-10 which has a Poly-Pressure keyboard however it is rather granular, ie, you can here the steps of the pressure changes unless it is used very, very subtly. almost to the point where you cannot really tell what is happening with more than one key pressed. That makes poly pressure of little more use than channel pressure (that affects all notes on that channel rather than notes independently).
I did want to see if you were interested in early code, either by email or just from an unannounced update on the website. I have to finalise the key assignment modes and then perhaps get you a copy whilst I finish up the details.
I'd say just use the modwheel for expressiveness! :-D
I don't mind if you e-mail it or just through unannounced update, but my e-mail address is countfuzzball*at*gmail.com
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.