Duggle

It is conceivable, that in overdrive and distortion fx stages, where there is extreme gain involved, that non-linearity of semiconductors gets amplified to the point of audible differences. Especially where the said components are there to shape the sound in particular non subtle ways. Though I doubt that many have the patience to set up ABX trials that allow them to objectively compare. The DIY HiFi enthusiasts can be completely insane in what they think they hear and the differences they believe are there. Monster Cable anyone? How about a felt pen for your CDs? True double blind listening tests (e.g ABX methodology, etc.) are rarely, if ever, used to determine what is actually audible. Rather, with experimenters, it tends to be left to the imaginings in the ears of the beholder....

It sounds like a really cool project and I'll offer my take: To add to this, one's ideas of how this kind of gear is used is often altered by the experience of actually using it in the creative context. So there is a catch 22 when designing very specific arrangements of gear. e.g you design and build a beautiful control surface to find that you really need some specific buttons and knobs that didn't occur to you at design time. A lot of work (and possibly expense) has to be redone to achieve your goal in its fullness. May I suggest building the SID and SEQ as standard, standalone units (in low cost enclosures) start using them and learn all about them in a practical creative context. Then combine them (possibly using the units as "modules") fitting them within a common enclosure/front panel, this way you can cater for the changes that I suggest you'll likely want. As for the velocity sensitive keyboard: how about rebuilding a low cost 2 octave midi keyboard (cheap/2nd hand) into the enclosure of the SID/SEQ combo. I think the control surface real estate of these units will be as wide as a 2 octave span. To summarise: I think a standalone workstation is a great idea, but it needs to be developed step by step (having fun using it along the way!) .

Sorry, I cant get a link to the actual www.ucapps.de page, but its the MIOS32_COM functions reference. Have you seen this? Also there are app examples in the repo, I believe.

I'd suggest that the timing between switch closures will be of a similar order of magnitude. (Eg if they're half the distance of the Fatar, then it is straightforward to compensate ie double the scan rate and adjust the timer count to velocity calculation) There is some flexibility at the Core end to increase SRIO scan rate if necessary and the timer used is of high resolution.

Correct, the spare hardware is spare for you to use.

If you want to press the thing that lights up, then look for illuminated momentary push switch (extra super large). Otherwise a separate button and light would do? (much more choices) There are sample apps that output midi events on the switch closure that will do the job. To drive the lamp/LED(s), assuming it has its own voltage/supply then a double pole switch is necessary to separate the midi from the lighting circuits. A relay (as suggested) or diodes can be used as alternatives (in the case where you have just a single pole pushbutton).

If you are using the pot to attenuate a headphone load, then you will want a pot with a resistance value similar to the impedance of the 'phones. Something like 100R log dual gang should do the trick. (not 100k like the french site.this value would be good for driving a hi impedance line input)

I dont have the code with me ATM, but I'll put it in a blog article with a link very soon (hopefully today). There are routines to get/set paged DOUT shift registers which go with mios32_dout.c they dont have to go in this file, but I found modifying the makefiles to build them from a seperate file difficult for some reason, so I put them here. It turns out to be neat and logical anyhow. On top of this there are the access routines to suit your application that you will be writing yourself app (i.e brightness modulation and matrix scanning etc). I'll see if I can provide an example of these.

It turns out to be a very natural concept: http://en.wikipedia....sity_modulation The changes to MIOS32_SRIO.c are small, simple (easy to understand) and are included/removed by a single #define variable which appear in the app's mios32_config.h . This way when paged DOUT is not required in an app the changes are not present.

Baar, you may be interested (or no) in a method i've been using to obtain PWM (actually PDM, in this case ) as well as matrix driving). It has no extra constant CPU load but it is at the expense of a little RAM and a little extra embedded code to Set/clear a LED. The idea is discussed in this thread: Since then Ive used it in some different contexts, works perfectly. I havn't mixed PDM and matrix but there is no reason not to. The implementation involves changing some SRIO MIOS32 files with a couple of lines of code, they can be removed for compiling apps which dont require them with a #define switch. If you (or anyone else) wants I can paste the relevant snippets to this thread. btw; PDM (pulse density modulation) works the same as PWM but has much less flicker because the highs are distributed in time across the cycle.

Indeed, and I think you may be being conservative, as there might be idle cycles while the transfers complete that could be used if needed, by increase SPI clk.

I think the correct answer is "yes, it is possible..to achieve a 24 X16". I say this because if it turns out to be constrained by i/o speed, it is possible to substantially increase the SPI clock. I havn't closely analysed the code but I have the impression that there is plenty of spare CPU cycles, as well.

The very small extra cost of the STM32 core is very worth while to say the least. There are many, many advantages of this as a platform especially, if you're developing and adapting application code for yourself, etc. It may seem like overkill right now, but this turns into flexibility, and room-to-grow, not to mention amazing real time performance. It has built in USB and many peripheral interfaces and options. (Forgive me for the going on about this, but the choice is clear, I reckon!)

Well no, but that could be good too! It could be something simple like a square array of 4 LDR's (say 5cm apart) each mapped to a different CC, so that different kinds of hand movement simultaneously control the 4 CC in relation to each other. This was how I interpreted your concept.

Indeed, you seem to understand that you wont be able to plug your camera or smartphone into the midibox via USB (..yet!) Actually a bank of LDR's as a straight up controller is a fantastic idea. Especially for simultaneous control of multiple params, as you say. I have a novation keyboard with a touchpad like a notebook PC. You can assign 2 CC parameters per axis (they crossfade in opposite directions, but also respond to multiple touches, a bit like mutlitouch) for both X and Y directions. It works really,really well. Explore all sorts of modulations just by moving the finger in a 2D "map". An arrangement of LDRs has even less limitations, but could be set up in a similar way.

Perhaps trivially, you've drawn the USB as a host connection. How do you plan to use the LDR's in the context of VJ'ing? (can think of interesting feedback setups with Midi controlled lights!)

Depending on what you mean by "sharing" variables, but one way to do save memory for temporary variables is to declare them within the scope of the function where they're used. This way they are generated from the C stack each time the routine is called and the stack space get used and reused over and over very efficiently (and is good coding style). Updating the flash program from eeprom (presumably frequently ) is likely to wear out the flash memory of the PIC. Its also nontrivial to code, unsupported, and I suspect, putting a huge hurdle between you and your desired project outcome :-( My suggestion is to get a job and go 32bit! ;-)

At a glance, it embodies the idea. two points I can make: 1. irq enable and disable is allready handled by the system. You dont need to call them when using these hooks . 2. you call noteon() and noteoff() on the pin state. This results in repeated calls on the same keypress (and keyoff!). You really need to call them only on a (debounced) transition! There are various examples in the repo to study to see how these tasks typically get done.

The mios32 arrays in your code are still the ram values that get used, and are unsynchronised with the actual transfers. If I was doing this the first thought is to set the DOUT pins in a routine called from inside: ///////////////////////////////////////////////////////////////////////////// // This hook is called before the shift register chain is scanned ///////////////////////////////////////////////////////////////////////////// void APP_SRIO_ServicePrepare(void) { } and then read the DIN pins from a routine inside: ///////////////////////////////////////////////////////////////////////////// // This hook is called after the shift register chain has been scanned ///////////////////////////////////////////////////////////////////////////// void APP_SRIO_ServiceFinish(void) { } In the repo Apps/examples is a 16x16 decoder app that uses another method: define an RTOS task that does the scan and calls the notify toggle hook. There are always very many solutions to a given requirement!

At a quick glance, I'd make the comment that you should use SRIO service prepare to set up the dout, and service finnish to read and process the din. By reading and writing in the background loop your setting and reading the ram image of srio transfers but you need to sychronise with the actual transfers that occur each millisecond.

Ahh! Now I understand why the encoder push function contacts are wired in parallel in Wilba's CS PCB!

I'm wondering about using the encoder 1..16 push switches as step pushbutton functions1..16 I dont know how the ergonomics will be? Anyone tried this? I guess the drawback would be that it is hard to push the encoder knob without turning it a little? I building a "mockup" MBSEQV4 to explore before building a full featured one with CS PCB and nice case (group buy one looks great for this, btw).

Yup, I got mine too! thanks v.much Wilba!

Hi, I've been contemplating similar themes. I've actually signed up for the group buys of full control surface hardware, but I think it will be a while before it all manifests into deliverable reality. In the meantime I plan to play with a core and two 40x2 LCD's and access the user functions by midi events. I also reckon the BLM emulator (available on PC iirc) would help with the exploration as well. I suspect its the kind of thing that you can only judge through experience!