Re: hardware problems

[rutgerv]

Haha, thank you both, TK and Wilba!

I'll leave out the MIDI led on the frontpanel then! I don't need it anyway since my MOTU midi patch bay already has activity LEDS.

I'm really looking forward to the more advanced CC options however! Especially the sustain (CC #64) parameter is very essential for me as a live musician, because I use it to play more parts with less fingers ;). For instance I hit a lowish note (drone-like sound) at the SID synth and hold it with the sustain pedal while playing other parts on different instruments over this drone. A 'default' assignment of the sustainpedal in the SID software would therefore be very nice!

Kind regards,

Rutger

ps. TK, MBSID V2 is still kicking ass sound-wise ;)

[TK.]

I'm really looking forward to the more advanced CC options however! Especially the sustain (CC #64) parameter is very essential for me as a live musician, because I use it to play more parts with less fingers ;). For instance I hit a lowish note (drone-like sound) at the SID synth and hold it with the sustain pedal while playing other parts on different instruments over this drone. A 'default' assignment of the sustainpedal in the SID software would therefore be very nice!

Since I've already overworked the note stack handling to realize a hold function for the arpeggiator, it shouldn't be a big problem to control "common notes" the same way when the sustain pedal CC is active. I will add this to the next release.

ps. TK, MBSID V2 is still kicking ass sound-wise ;)

Thank you! :)

Best Regards, Thorsten.

[rutgerv]

Very very cool!

Greetings,

Rutger

[TK.]

Ok, I've added the hold pedal function, please try it out - hope that it works in real life :)

-> http://www.midibox.org/forum/index.php?topic=9457.msg67779#msg67779

Note that it currently only works with Lead patches, and I'm not happy how it behaves with WT sequences. So... it still needs some improvements.

Best Regards, Thorsten.

[rutgerv]

Wow, TK, that's fast! Do you ever sleep?

I'll try it tonight and see if it works in my setup.

Greetings,

Rutger

[rutgerv]

I just uploaded Beta 8 and the new sustain function is working very well!

Rutger

[rutgerv]

Ehm, almost ;) After some testing I discovered some anomalies in the sustain handling. When I press a note, press the pedal and release it again (while still holding the note with my finger) the envelope retriggers...while I believe it should not. I believe that somehow the software should keep track of note-off commands from the keyboard during pedal-hold. If a note off occurs and no new note-on command occurs the pedal can 'mute' the note when it's released. When the note is still played on the keyboard while the pedal is release the pedal action should NOT mute the note.

Hope that this info helps on improving the pedal behaviour. Other than that, great work! At the moment I'm running experiments on the temperature stability of the filter. I've created a filter envelope on a lead sound that I want to go from 'just above audible cutoff' to completely open filter and see if the envelope stays the same over time and temperature.... I've omitted the temperature compensation of Rick Jansen's schematic to keep down costs and construction difficulty. My goal was to make this filter a bit more friendly for the average MidiBox-builder in the sence of costs and part availablilty through Reichelt.de. If all works well I'll share more detailed info on the filter with everyone.

Greetings,

Rutger

[rutgerv]

Oh, I almost forget.

I'm really really looking forward to the Super Poly mode for the new V2. I recently had an email conversation with Wilba about it since it's interesting for almost anyone who's building the 8xSID midibox in some form.

Some ideas I had on how this Super Poly mode could look like are:

1. The first 'generation' of the Super Poly mode should not nescessarily use the CAN-bus for all data communication (including all notes to the slaves). Instead the master core could send only enable/disable commands over the CAN-bus to the slaves that enables or disables the response of a certain SID to an incoming note event on the midi-input. This will keep down the load on the CAN bus and the midi-in wiring doesn't need to be changed.

2.  Each core could have an enable 'SuperPoly' switch that automatically sets the midichannel of this core to the midichannel of the master core. The number of slave cores set to 'SuperPoly' automatically determine the number of voices available.

3. I believe that the most interesting forms of SuperPoly mode are 8-voice mono and 4-voice stereo. 6-voice mono with an additional monophonic sound on a different midichannel on the remaining core could also be interesting (for a bassline). Each voice would have 3 oscillators (1 voice per SID). That way you have a filter per voice. In the case of 4-voice stereo you could even keep the entire lead engine setup. In case of the 8-voice mono mode the PIC cpu power will probably not be enough to account for all LFO's, modulation, etc of the lead engine.

That's just some of my thoughts. If I can help in any other way, please let me know.

Greetings,

Rutger

[TK.]

When I press a note, press the pedal and release it again (while still holding the note with my finger) the envelope retriggers...while I believe it should not. I believe that somehow the software should keep track of note-off commands from the keyboard during pedal-hold. If a note off occurs and no new note-on command occurs the pedal can 'mute' the note when it's released. When the note is still played on the keyboard while the pedal is release the pedal action should NOT mute the note.

the firmware keeps track of notes which are still pressed, and notes which were pressed before sustain was enabled, and are not pressed anymore after sustain has been released.

This issue is probably related an unexpected corner case in the patch configuration.

Which play mode are you using (mono/legato?) - and what is your trigger matrix configuration.

Or are you using a preset patch? Which one?

Poly mode: I can understand your impatience, as I can understand why so many people frequently ask me via mail, when I will finally implement feature A, B or A&B, and why A before B, and why not D and E in addition, as I'm coding so quickly?

I don't want to start discussion here, why your thoughts are not working completely (e.g. why it doesn't make a difference, if Note events are transfered via CAN, or enable/disable events). I also don't want to discuss, why your ideas for different configurations won't work as you currently think, etc...

Such discussions are just too time consuming for me.

I don't want to repeat myself, but maybe I wasn't clear enough last time: PLEASE let us discuss the requirements for suply poly after the v2.0 release, when I have a clear view about the possibilities.

Be happy, that I haven't already cancled this idea - it will cost me an immense coding, debugging and support effort.

Best Regards, Thorsten.

[TK.]

P.S.: you can help me by creating a *lot* of new patches for the user library - I need such patches as "testpatterns", so that I'm able to check if all engine functions are still working when I'm doing changes.

Other things which are missing:

  - a Java based bank manager

  - a Java based SysEx editor (for people who don't build the CS)

  - improvements in the user manual whenever something is not clearly described from my side

Best Regards, Thorsten.

[rutgerv]

Hi TK,

I understand completely. My reason for sharing my thoughts on the SuperPoly mode is not to put pressure on you but to keep the item open for discussion with other people. I just like to think about and discuss these design-related issues and I'm also curious about what other people think about it. I tried to point out what approach of the Poly-mode would be interesting for my use and I'm interested to hear about other people's opinions.

So again, no pressure on you, TK! You already did an amazing job on the current V2 beta release! I'm even surprised that you call it 'Beta' ;) and I'm not at all concerned about taking the SID synth with me to a live gig, even with the Beta version running on it!!

Greetings,

Rutger

ps. I'd be happy to supply you with a bunch of new patches! However, because of my hardware, most of them will require an external filter. Do you still have the CEM's or Moog filter attached to the AOUT of you MBSID V2?

pps. I'll be moving to a new appartement in Nijmegen, Netherlands by the end of this month for a new job on Brain-Computer Interfaces (i.e. controlling a SID synth with your thoughts ;)). After I finished moving I'll install Java again and see if I can come up with a  nice editor. I only have the plan B control surface so I'd like a good editor myself and I have experience with several bank managers and editors (i.e. SoundDiver, etc).

[TK.]

ps. I'd be happy to supply you with a bunch of new patches! However, because of my hardware, most of them will require an external filter.

thats ok, I guess that they will also sound cool with SID filters, and if not, slight changes should help.

Do you still have the CEM's or Moog filter attached to the AOUT of you MBSID V2?

I've CEMs, Moog and soon SSM (dontated by Seppoman :))

Best Regards, Thorsten.

[rutgerv]

Very cool, those SSM's! I recently did repairs on an Ensoniq ESQ1 by the way. Very clearly it's the work of Robert Yannes again, just like the SID! I really like the sound and the implementation of the Operating System. Simple but very flexible. He also uses 8 CEM's controlled by a DAC.

Greetings,

Rutger

[TK.]

I just like to think about and discuss these design-related issues

Design related issues which you could discuss without my attention (they can be propably solved during a long weekend...)

  - how to realize CAN transfers with so that they don't block the MIDI engine to avoid risk for buffer overflow at MIDI receiver and/or CAN receiver side (possible solution: rearrange the message buffers, use special ID mask, so that some of them can be used for queuing incoming broadcast messages - don't use handshaking here - needs complete firmware before it can be evaluated)

  - how to organize the note stack at the master side, so that it can handle all the different modes (than more ideas from your side, than more difficult to find an universal method - possible free memory depends on RAM allocation of final v2.0)

  - how to handle portamento (don't know how to transfer frequency variables fast enough from one to another core before the next SE update cycle)

  - how to handle arpeggios and arp events (wavetable) (no idea)

  - where to store the different modes in the ensemble structure so that future extensions are not blocked

  - how to configure them exactly at the CS w/o consuming too much memory, so that other nice features would have to be cancled (no idea, always very time consuming definition task)

Best Regards, Thorsten.

[TK.]

The first two issues have been solved (see http://www.midibox.org/forum/index.php?topic=9947.0)

Sometimes it's important just to think different in order to find an elegant solution ;-)

Best Regards, Thorsten.

[stryd_one]

It also helps if you have TK's gigantic brain.

;)