MBSID V1: new release candidate(s)

[TK.]

I don't want to misuse the V2 thread for introducing new V1 release candidates anymore, therefore this new topic.

Razmo requested two changes in the arpeggiator handling to improve the usability. I found both very useful, and have build this into the application as default option (the old handling has been replaced by the new one!).

Here the description in Jess' words (he can explain this better than me :):

I only have ONE thing that I'd REALLY like to see done on V1, and that is a

change to the arpeggiator. I do not like the way it works at the moment. I

think it should alternate between just the keys pressed, and that every note

should have equal amount of time to sound... As it is now, if you press only

two keys, the time is split up into four equal time-parts meaning that one

of the pressed keys will get thre shares while the other only get one... The

notes pressed should simply alternate up to a maximum of four notes with the

rate given for the arpeggiator. You can play some really cool stuff live

with this approach (which is in fact a standard arpeggiator as found on all

synths).

An extra alternative way of doing it (I did this on my synth) is if the

arpeggiator rate is instead divided among the notes pressed.... it's

complicated to explain, but if you for example have:

An arpeggiator rate of say 100ms, then if you press one key, you will get

just that note playing.. nothing special there...

If you press TWO keys, then these two notes should play in alternating

fashion, alternating every 50ms (100ms/2notes).

if three keys are pressed, every note recieves 33ms each (100ms/3notes)

and finally; four keys pressed each recieve 25ms each (100ms/4notes)

Using this technique make certain that the "broken cord" will sound very

different... and in fact BETTER! ... It will also be a technique that I only

know ONE other machine has... the Droid synth. this gives great live

performance playing advantages...

The same from the ChangeLog:

  o the arpeggiator has been overworked, now the arp cycle has always

    a constant time. If one key is pressed, it is stepped with normal

    rate, with two keys at double rate, three keys triple rate,

    four keys quadrupled rate.

    This approach improves the live handling and yields more musical results

    If the arpeggiator is synched to MIDI clock, use following

    rate settings:

      - 64th note: 124

      - 32th note: 118

      - 16th note: 106

      - 8th note: 82

      - 4th note: 34

Link to application: http://www.ucapps.de/mios/midibox_sid_v1_7303b_rc6.zip

Best Regards, Thorsten.

[js]

I tried out this new version, and find it very usefull. Thanks alot!! :) One thing I don´t understand though. Do you have to use external sync to makeit go very slow?

This is how it sounds when with the arp setting on 1 (and change it to 0)

http://home1.stofanet.dk/js/cc/arp.mp3

Thanks again

skov

[Razmo]

Hi js!  :)

I've been asking TK about the rate of the arp also, but he told me it would be hard to implement lower rates. Also, the "divided time" arp feature now implemented will probably not sound very effective at low rates, because of the alternating speed changes, it's better suited for fast broken chords. In V2, I believe TK will make it switchable between a normal arp. and this new one, so that when you want classic arps, going slower, you can chose the right arp type.

The good thing about the new feature is, that it sounds really beutiful also when playing melodies instead of just simple chords... with the old version it was not really useful on other stuff than chords. With this new feature, if you play it right, you get the kind of "thrills" from it, that you do when playing flutes and other wind instruments... REALLY good for renaisance and old times types of melodies...

Regards, Jess.

[Razmo]

Here is a little demo to illustrate what I'm talking about... PLease bear in mind that it's played live!  ;D

http://media.putfile.com/Arpeggiator-Demo

Regards, Jess.

[Jaicen]

So is it possible to get an arpeggiated sequence that sounds like a Juno?? That's the yardstick against which I compare all others. From the sound samples, it seems that the MBSID runs way too fast for that.

Nice bit of reneissance there Razmo ;)

[Razmo]

Thanx Jaicen  :)

Here's another little demo of a patch I'm working on using sync... Yep!... SID goes Blade style!  8)

http://media.putfile.com/Sync-Lead-Demo

Regards , Jess.

[js]

Thanks for letting me know. I really like the new version, but I miss the posibillity to sweep the arp speed. A funktion to change the arp version would come in handy later :)

Nice examples :) expecially lige the last par of the 2nd one ;)

js

[Davo]

Here is a little demo to illustrate what I'm talking about... PLease bear in mind that it's played live!  ;D

http://media.putfile.com/Arpeggiator-Demo

Regards, Jess.

Hrm... I can do that easily on a monophonic synth.  At least for me, it's very similar to doing gracenotes on the bagpipes or tin whistle.

Davo

[Razmo]

Yes, you can do it on a simple monosynth too... but there is some differences. I don't believe many arps on other gear reset the arp on every key-press (it does not make sense, since the normal arp is meant to play at slower rates than a SID arp, and it would sound bad if it did on slow arpeggiating patterns), and also, the speed of the arpeggiated notes do NOT change their rate based on the number of keys pressed. On my demo, of course no more than two notes are pressed at the same time on those thrills, so with a standard arp you could do something that sound very similar... but to sound exactly like the arp demo, the arpeggiator must be syncable to key-pressings.

Regardsm, Jess.

[TK.]

The arpeggiator runs slower when you synchronize it to an external MIDI clock. Just enable this synchronisation (via CFG menu, JSynthLib or CC), and try out following arpeggiator rates:

   If the arpeggiator is synched to MIDI clock, use following
     rate settings:
       - 64th note: 124
       - 32th note: 118
       - 16th note: 106
       - 8th note: 82
       - 4th note: 34
[/code]
MBSID V2 will provide an alternative internal BPM generator, but if you synchronize your gear from a host sequencer anyhow, you will be happy with external clock synch (which is already available)
Best Regards, Thorsten.
P.S.: nice demos, Jess :)

[js]

Often i use it stand alone, so I don´t sync it. Going to try it on tuesday when im at work. The BPM generator sounds fantastic, Actually thought of it today. Thought of the possibillyties if it included a tap tempo funktion.  :)

js

Edit...: I bet that Razmo aka Jess is a fellow Dane (we even have the same name :) =Skov )

[Razmo]

Hi js!  :)

Yep!... Den er god nok!... Jeg er dansker og bor i Næstved  ;D

And for you non-danes it says: "Yep!... It's true! I'm a dane, and I live in Næstved" ...  ;)

Regards, Jess.

[js]

heh, thought so. Havn´t noticed meny danes here though  ::)

js

[Rio]

I've tested beta_15, but don't know, whether this is corrected in last version.

The LFO VU-Meter looks nice but works only for MASTER-Core-Board. If i choose the next core's (SLAVE ID:01,02,03) the VU-Meter aren't changing, representing the settings for MASTER-Core further.

Another annotation is that all activated or deactived LFO/ENV VU-Meter are shown. It would be better, that only the active LFO enables the VU-Meter, which belonging to it.

[TK.]

Hi Rio,

it's not possible to determine the current LFO/EG meters of a slave, therefore the matrix always shows the values of the master.

Does anybody have objections against Rio's proposal, to show LFO/EG meters only when they are routed to a target?

Best Regards, Thorsten.

[stryd_one]

I understand that this could be confusing to those who are not aware of the behaviour of the MBSID, but I don't think that obscuring the information serves any purpose other than to clarify the operation to newbies. I'd rather see the less relevant information than not see any info at all..

I think the master LFO/ENV should be shown at all times. Sorry Rio! :-\

[Rio]

thats ok.

But most sadly, i don't see the slave VU-Meters, so the VU-Meter option is for me secondary.

1. So how can i assembly the source, so that the VU-Meter is first at start of application are deactived and the settings for matrix are visibled.

2. It would be nice, if i choose the 2nd, 3rd, 4th SID, that the VU-Meter will be deactivated automatic, because its only a information of the master. If i go back to the 1st SID the VU-Meter should than be shown again. If no VU-Meter are activated on master, then nothing should happen on changing. ;)

[stryd_one]

2. It would be nice, if i choose the 2nd, 3rd, 4th SID, that the VU-Meter will be deactivated automatic, because its only a information of the master. If i go back to the 1st SID the VU-Meter should than be shown again. If no VU-Meter are activated on master, then nothing should happen on changing. ;)

This seems an exercise in improving aesthetics at the expense of function and information.

Don't you think the code space could be better used to add features than to remove features??

[Rio]

hey are you developing the asm-source? let TK decide. it's an inquery of one(!) flag!

[stryd_one]

not for this project, but i've done enough to tell you that it's more than just one flag, you've got to have code in there to do something with it.

and you still didn't answer my question....but your response indicates that you missed the point which is that no matter how small or simple it is, it's code space (and ram) that could probably find a far more beneficial use than removing somthing which isn't that big a problem.

are you copping attitude at me or what? Cause it sure sounds like it !

[stryd_one]

Does anybody have objections against Rio's proposal, to show LFO/EG meters only when they are routed to a target?

Just in case you forgot why were discussing this. TK asked for our objections, I'm giving mine.

[Rio]

I'm talking about the visuals VU-Meters on slaves which are belongs to master, this could be annoying by choosing new sound elements on slaves and it's not a removing feature. It's my position and not more.

[stryd_one]

It is a removing a feature, because as it is now, you have master meters shown for all sids. What you are suggesting is to remove the master meters when editing the slaves. If you know that the meters always display the levels of the master, then I don't see why it's so annoying.

As for only showing the meters when they are routed to a target, I think that is not an improvement either... I'd rather be able to see the meters so that I can visualise the synthesis prior to engaging it. This kind of thing is especially useful in live setups.

[Rio]

yes it's an experience. So it'll be necessary to check this out.

But for me it's better to have disabled first the VU-Meter by start up application. only if i press the 2 Buttons.

[TK.]

It is difficult to enhance the meter code, so that only activated LFO/ENVs are displayed, because the informations are located in different variables - each modulator needs different masks.

So, it's nothing which can be done and tested within one afternoon (from my experience, I would build in at least one new bug ;-)

I'm happy with the current handling, and I would like to continue with new stuff, is this ok for you, Rio?

Best Regards, Thorsten.