Duggle

It seems the forum software was (quietly) upgraded lately. Can anyone tell me how to insert a picture from a gallery into a forum post? Thanks

My latest acquisition is a Virus C (a.k.a.Rack XL), it has: 123 parameters on page "A", 124 parameters on page "B", 127 parameters on page "C" The Virus B has nearly that many. Almost every parameter on A and B is commonly used in patch design, page C has multi and global parameters (less used). Making the programmer "larger" is impossible! However clever bank design will be important. Question is: is it better to have 64 knobs with terse labels and display feedback, or 32 with very explicit labels and clear feedback? I'm not sure but I've been using my midibox64 now and then over the years and have found the lack of feedback a real problem with it's efficient use.

Where did you read this? (please provide link).

255 LCD's amazing! 512 characters less so :huh: What number of CLCD do you see as the upper limit before electrical buffering is necessary? I take it that the buffering would consist of the LCD output J15 driving a number (say 4) inputs of non-inverting buffer for each signal of the LCD bus? (Assuming the buffer can drive 4 LCD's, thats 16 LCDs, and 4 sets of buffers, a driver gate for each of D0..D7,RS,RW [10 per LCD]. 5 octal buffer/driver would be sufficient in this scenario. The enable lines would be wired 1 to each display so need not be buffered. I'm very serious about building a synth programmer for my Virus's. Ebay has many suppliers of backlit 16x2LCD for <=$3 each including postage! The question is: do I go for 32 encoders (16 chars of display per knob) or 64 (only 8 chars of display per knob). Or a mixture?

I remember seeing (can't find it now), a list of LCD size versus number of displays simultaneously driven by an NG app. What are the current design limits for number/size of character LCDs supported?

You'll be needing a core module plus DINs (based on your description). Encoders use 2 DIN pins each. If you want to wire as matrix 8x8 (1DOUT SR+1 DIN SR) This covers 64 buttons so x2 to cover your 80.

The velocity values would be a lot more "granular" i.e would encompass the range 1 to 127 but certain values would never appear on the output because it would map 5..100 onto 127..1. With nonlinear scaling it would invariably reduce the total number of values that appear on the output. Would it ever be noticed? (imho) no, does it bother me (mentally) that the velocity output would be granular, yes :hmm: . Personally (subject to change, of course!) I might entertain the idea of developing on a small STM32 "minicore" (minimal MB Core32) that does nothing more than scan the keyboard(s) apply velocity scaling, then forward midi events to a uart (maybe at higher baud, for direct connect with an NG?).

Its always hard to accept higher latencies mentally, though in practice it often makes less difference that you think (esp. when its <5ms total). I am and will be using the KB through the SEQ which I assume adds 2ms to live notes forwarded through to synths (then latency of the actual synth added to this..) Am I correct in understanding that using optimized scan on a NG based KB may add only 800 or 900us to the total latency?

Ok, good the drivers are working as expected. You will not get 16 x 21mA through the single low side driver pin without the ULN2803. The crappy LEDs are saturating hence no extra light with more than double the current. Normally LED should be linear in brighness with respect to current up to, and often over, 20mA.

That's really cool! My idea for a control surface is (if I'm correct about the limits) is 6 of 40x2CLCD's each with 8 switch encoders mounted close (like SEQ) but also a well diffused RGB LED under or over each encoder. Thats 48 encoders, each incorporating a switch and RGB LED, and average of 2x5 char LCD space. With the knobs 4 above and 4 below the LCD it might be 9chars+1space per parameter. Now the purpose of the LEDs is to visually reinforce the logical connection of groups of parameters. Say in a given bank all parameters of FILTER1 were Light Green, and all the parameters of FILTER2 were Pink, it would not only make the bank, when selected, instantly recognisable, but it would save LCD space because "FLTR1" text above each knob of FILTER1 would be redundant and the characters saved put to better use.

Damn! if it was the other way round there would be a firmware fix for this! This suggests the current limit is imposed by the high side driver (and made a problem by the the low duty cycle). If you wanted to investigate it further: if you where to place a couple of CRO probes across the resistor, set the scope to subtract signals.This way you'd be measuring the instantaneous current (I=V/R) through the R ,LED and driver. Accounting for different values of R measured, you may find the current varies less (than expected) as result of the high side driver output stage being saturated. It looks as though they are really dim LEDs (low mcd) you have there. Your approach of better LEDs may be the only practical fix.

Is the matrix being driven such that the low side driver (the DOUTs connected to the ULN2803) is driven 1/16 duty cycle? In other words each ms one low side driver is low and the high side (DOUT connected to resistor network) has a pattern of 16 LEDs for a single LED ring?

I think it was my idea to add the ULN2803 to design :happy: It does provide a much more substantial current drive to the LED matrix, however it does (I have since discovered) have a minimum output voltage of 0.6 to 1V. So it is therefore necessary to compensate with lower series current limiting resistor(s). The driver can sink a lot more current than a single HC595 pin, I promise! TK, if you could when you get a moment to do this, solder another resistor across (in parallel with) one of the resistors in the 220R resistor networks. I suggest trying a value of 180R or thereabouts. This should result in the same LED in each LED ring being about twice as bright as the ones next to it?

Another related idea is the following: Say you have a synth and you design a bank which accounts for 1/4 of the synths params. You access all params of the synth by a group of 4 radio buttons. So far (as I understand) NG gives us this. Now (continuing the above example), say each bank consists of 4 (or 6 or whatever) rows of encoders. I could have the 4 radio buttons replicated beside each row of encoders. This way it would be possible to swap in an entire row from another bank. This could be a good way to simultaneously control parameters from another piece of gear: say an fx unit that only has 10 parameters might temporarily inhabit 1 row of a synth bank. Maybe a single button (to cycle) or encoder beside each row for bank selection would work.

Correct! [edit] Actually think this might be more useful than I first thought. It allows to see (and change) parameters from different banks.

So the idea is that with a synth with many parameters it will be impossible for there to be a dedicated knob for every parameter. Hence the feature of Banks in the NG system. The idea is to have a group of radio buttons (each with a LED of course) to select Banks (or "pages" as I think of them) of parameters. The Access Virus for example has well over 100 parameters. It may be possible to reach all of them via 4 banks of 32 encoders (but definitely with 6 or 8 banks). What about the realtime tweaking of 2 parameters? This is ok when the're in the same bank, but impossible otherwise. My idea (maybe unnecessary, gratuitous, stupid) is to be able to access parameters on other banks individually by stepping through the banks of an individual knob by pressing on the encoder switch. A bank select button would change all controls to the same bank, as expected. It follows that if the 2 parameters from different banks where positioned on the same knob, the position of one of the parameters would need to changed in order to accommodate that particular combination (by editing the NGC file, or create further banks with the same parameters in different positions). Maybe the concept has merit as a way of making on the fly custom banks. I don't know, but I thought I'd mention this NG design topic.

I've been thinking about the spline approach you suggested. According to wiki a spline is a piece wise function where different segments of the domain are evaluated by different polynomial functions. There would be a "run time" part where the velocity of each note event is calculated. Also, another part which runs when a new curve setting is made by the user, which calculates the coefficients of the polynomials. I'm thinking that by specifying 3 spline "knots": start (similar to delay_slowest), end (similar to delay_fastest), middle (the delay time specifying a point between 2 polynomial curves), shape1 (determines curve of 1st polynomial), shape2 (curve of 2nd poly). The polynomials would be 2nd degree, parabolic. This would give a very wide range velocity curves without too much complexity, especially the run time function (which need to be reduced to integer calculations). I'll have a play with some maths packages and we'll see how I go!

I've found that the variable set by set srio_num 4 is set correctly to 4 but only until the next power up where it reverts to it's default value of 2. The result for me is that kb 2 is not active until I issue the above command (despite having previously typed the store command). thanks

I'll look at the firmware, thanks for the link. I'll think about the v curve options. Perhaps a system of presets with the alternative method of modifying the underlying parameters, would suit most users. I suppose with pitchbend one would want the full range of digital values produced and to have the synth/receiver determine how it responds. This suggests a one off calibration procedure where the min and max values of the sensor are acquired and stored in eeprom. If the pitchweel is spring loaded, then it may work to have the value acquired at powerup used as the center.(keyboards commonly use this method to work out if a footswitch is normally open or normally closed.) In addition any constant reading in the neighborhood could be taken as "zero". I'm thinking the only way I've seen it done. The sustain pedal only sends the CC, and the receiver decides how to process it. The way of "pre processing" the sustain of notes is interesting, but should definitely be just an option IMHO (actually it would be handy in certain circumstances such as recorded midi data where the CC event is edited out or otherwise lost, however it suffers from the fact that "information is lost", you could not edit the performance of the sustain pedal after the act of recording).

I've just built a dual manual (upper and lower) 2x 61keys using 2x 5 octave velocity sensing key board from Fatar sourced through local Doepfer agent. I've used a standard LPC17 MBHP Core, 2x DIO Matrix PCB, connected as per the excellent doco and instructions set up by TK. It works! There is room beside each keybed for mod wheel and pitchbender. Some observations (and questions): The suggested settings for velocity response are a bit "top heavy" (Meaning the average strike gives a velocity of over a 100). I think I prefer it if its in the 40 to 60 range. This way it is easy to perform accents, more dynamic.I've improved this a little by making delay_slowest smaller say 1000 (the suggested was 2000). Better, but still not proving a very smooth transition from soft-light to heavy-fast.I suspect a concave velocity curve is what I'm after ( with increasing velocity on input, the output velocity increases from left to right on a velocity curve diagram.) Rightmost curve, below.The pitchbend modwheel combo I'm thinking of fitting to each keybed is a Doepfer one. It states on the website that the potentiometer on each wheel does not travel the full distance. In other words, if 0 and 5V is attached, the wiper voltage will only go from 0 to about 1.6V. I assume the best "fix" for this would be in software?The pitchbender has a centering spring, I would assume the software would need to recognize when the bender is "at rest" to provide a pitchbend of "zero"?I would like a sustain pedal for each keybed. I assume the most straight forward interface for this would be the analog (using pullup/down resistor) with each footswitch? (It would mean I'm using all (6) analog inputs.)I've not seen the firmware source code yet, I assume it is/will be available?Thanks TK, for putting together another great midibox project!!!!

That sounds great, TK. I was playing last night and referring to the manual, I'll be at it again this morning... But I wasn't able to actually enter song mode for some reason, though I was able to enter actions to action list. I'll be looking again shortly.. It's early days configuring my rig really, the rc-50 midi implementation is very limited and idiosyncratic. If I can get it to work, it may make sense, to have the rc-50 patch change with commands from the SEQ (mixermap song actions) that way songs could be stitched together into a set. It would also (simultaneously) be extremely useful to jump to a song if it was patch selected on the RC-50. If the midi implementation on the rc-50 is not bogus this should be possible (the rc-50 has its own midi "modes"). I'll find out today. Anyhow a configurable method of song loading, phrase triggering would be very welcome!