Group Buy Custom FX Controller

[siniarch]

Originally Posted by Pompeysie

Awesome. Do keep posting updates when you can.

Thanks for the interest Pompeysie. I actually had my PCB designer order about 4 encoder PCB boards and 1 button PCB boards to be printed and enough parts to make the next 20 encoder units. Once they come in, he will be testing them on his bench and finalize the Main Controller PCB Board and programming the Encoders for midi.

I'm also including an RJ45 plug and I'm going with the most expensive MCU (the processor unit) so in the future we can make the unit work with OSC. I'm hoping we can do a firmware upgrade in the future that will allow it to work with OSC and be able to use that protocol's precision. Midi is only 127 levels of precision while OSC is 1024, so it's substantially more accurate. My guy is only familiar with MIDI, so I just want to get this done working with MIDI first and in the future I will work on OSC even if I have to pay this guy to learn to program in OSC.

So progress is coming along. I just don't want to bore people with the tedious details, but I guess it's good to update to keep the interest going.

[Funkybot]

Yes, please keep us up to date. Very interested. Any ballpark on cost yet?

[siniarch]

Originally Posted by Funkybot

Yes, please keep us up to date. Very interested. Any ballpark on cost yet?

Not yet. I'd like to do a cost analysis once I have the entire thing designed. I'm not sure if my guy is using the cheapest place to get everything and to print the boards. But I don't want to slow down the development process, so I'm just going with whatever place he's used in the past.

I'm still sourcing the color buttons because I can't find full RGB buttons yet. So I need to spend time looking for those at the moment.

I kind of wish I had the enclosure started already, so when things are printed and shipped to me I can assembly it right away, but without knowing the entire layout of the main Controller board, there is no sense in doing the enclosure. Most likely it will be done in metal. I know when mass producing, the hard plastic enclosures would be more cost efficient, but when doing small runs, you save on the high molding cost of the plastic enclosures. Plus I like the idea of a solid build like a tank enclosure.

[siniarch]

The initial printed boards came in today. Once the other components arrive today my guy will be soldering them together. Pretty exciting.

Hopefully by the end of the week, we'll have a working prototype even if it's only with 4 encoder units.

[siniarch]

Encoders in action:
1. Lights are working
2. Push button is working
3. Touch sensitivity is working



https://bit.ly/SiniCon24_Development_0001

click link for video.

[Pompeysie]

Originally Posted by siniarch

Encoders in action:
1. Lights are working
2. Push button is working
3. Touch sensitivity is working



https://bit.ly/SiniCon24_Development_0001

click link for video.

Fabulous!

[Funkybot]

Nice progress! I know nothing about how to integrate firmware into a device like this, but is MIDI 2.0 on your radar? Seems like MIDI 2.0 would create a standard for DAWs and other devices to communicate parameter names and values via a standard protocol. Obviously DAWs and plugins would need to support it, but a box like this could eventually just pick up the parameter name and values without having to do any workarounds and mapping, which would really kick ass once everyone catches up to supporting it.

[siniarch]

Originally Posted by Funkybot

Nice progress! I know nothing about how to integrate firmware into a device like this, but is MIDI 2.0 on your radar? Seems like MIDI 2.0 would create a standard for DAWs and other devices to communicate parameter names and values via a standard protocol. Obviously DAWs and plugins would need to support it, but a box like this could eventually just pick up the parameter name and values without having to do any workarounds and mapping, which would really kick ass once everyone catches up to supporting it.

Currently not looking at MIDI 2.0 yet. Making it with the ability to upgrade the firmware and hoping once I get it working I can upgrade it to OSC so it can work over network protocols. But I'm not against looking at MIDI 2.0

But, first thing is getting this unit functional with regular MIDI, getting it to work with REAPER an CSI. Then I have to gauge the demand. If there is a market for it, I will certainly investigate OSC and MIDI 2.0. Thanks for the suggestion.

[Piszpan]

Hi,
I have some questions:

1. Will it control VST synths or only FX's?

2. If yes, what method of selecting a VSTi would be used? (Active track?)

3. If the controller will focus on the active track, will there be dedicated < > buttons to change track?

4. What about a dedicated button for opening closing plug-in editor onscreen?

5. Will this controller support pages? I mean: 24 parameters is not much - but e.g. 3 or 4 banks (pages) of 24 parameters would do the job.

6. In what order will the parameters be displayed? I mean: only the default order set by plug-in developer or will it be customizable?

7. Please, don't do faders. Faders collect dust.

[siniarch]

Originally Posted by Piszpan

Hi,
I have some questions:

1. Will it control VST synths or only FX's?

2. If yes, what method of selecting a VSTi would be used? (Active track?)

3. If the controller will focus on the active track, will there be dedicated < > buttons to change track?

4. What about a dedicated button for opening closing plug-in editor onscreen?

5. Will this controller support pages? I mean: 24 parameters is not much - but e.g. 3 or 4 banks (pages) of 24 parameters would do the job.

6. In what order will the parameters be displayed? I mean: only the default order set by plug-in developer or will it be customizable?

7. Please, don't do faders. Faders collect dust.

Hi Piszpan,

I will link this controller to REAPER with the CSI Project. With the CSI project you can map almost any controller knob, button, etc... to almost any action in REAPER. So basically the possibilities are endless as far as customization.

1. I'm actually not familiar with VST Synths, but as long as the parameters of the Synth are accessible to REAPER (which I believe they are) Then it will be able to control them just fine.

2 & 3. Most likely the method of selecting VST FX and VSTi would be the last selected track. But as I state above, it is customizable depending on user's needs. So I could definitely see either an encoder being used to go up and down the tracks or two of the bottom buttons (the unit has 8) to go left and right (or up/down) on the tracks.

4. Again, very easy to implement. If say, you were using and encoder to go up and down the tracks (for selection) then pressing the encoder down could be programmed to toggle Plugin Editor Onscreen. If you were using buttons, then a third button could be used to toggle editor onscreen. The encoders will also be touch sensitive so I think we could even make the encoder that selects tracks touch sensitive to toggle this. Meaning, you scroll up and down tracks. Perhaps pressing down selects the highlighted track. (not sure if reaper can highlight a track without selecting it.) but if it could. then tapping the encoder would bring up the editor and tapping it again would turn it off? Just a thought.

5. Certainly. The encoder could support pages. I don't want to say limitless, but I'm sure many pages could be configured.

6. Parameter order would be customizable.

7. No faders on this module. If this is successful and provided I can make my development money back if I do many more units, then I have plans on working on a fader only module. With the idea that all the modules could be linked to create larger controllers. Then people pick what they want.

Again, thank you for your interest and your comments. It's always good to know what people want and need to improve anything I'm doing on my end.

[Piszpan]

Thank you for detailed answers.

If you want to know "people's opinion", please take a while to read the following:

For the last five years I've been trying to find the best solution to control VST synths (and maybe also FX) inside Studio One and later inside Reaper. I ended with having multiple controllers and only came to conclusion that every single of them has some significant flaws.

So far, the best (in my opinion) is Nektar Panorama P1. My main concerns about it are:

1) Every time I switch the page/bank of 8 parameters, I have to wait for a second and *very precisely* move the knob which controls this function - that's the way it is designed. In practice it turns, that I sometimes prefer to grab a mouse, becasuse... it is quicker (sic!).

2) Some buttons on Panorama P1 are too stiff and awkward to use (although the encoders are very good).

Overall, my over five year experience with a multitude of controllers, scripts, configs etc. drove me to this conclusion:

EVERY SOLUTION IS, SADLY, ONLY AS GOOD AS ITS WEAKEST POINT.

Many designers have some brilliant ideas, but one or two things can in practice ruin the usability of a given product. So far, every single solution I tried has some kind of a showstopper.

You seem to bo on a right way, but bear in mind, that your design needs to be *VERY good*, as *only good* is not enough. I have enough of *just good* controllers, that gather dust.

OK, now backing to your project:

1. Please, make the font in the displays AS BIG AS POSSIBLE. Otherwise I couldn't imagine using your controller in a live situation. (The current trend of putting microscopic OLEDs in synths drives me crazy.)

2. Will the encoders support acceleration?

3. I guess it'to early too say, but... will your controller be bus-powered?


Expect futher questions.

[siniarch]

Originally Posted by Piszpan

Thank you for detailed answers.

If you want to know "people's opinion", please take a while to read the following:

For the last five years I've been trying to find the best solution to control VST synths (and maybe also FX) inside Studio One and later inside Reaper. I ended with having multiple controllers and only came to conclusion that every single of them has some significant flaws.

So far, the best (in my opinion) is Nektar Panorama P1. My main concerns about it are:

1) Every time I switch the page/bank of 8 parameters, I have to wait for a second and *very precisely* move the knob which controls this function - that's the way it is designed. In practice it turns, that I sometimes prefer to grab a mouse, becasuse... it is quicker (sic!).

2) Some buttons on Panorama P1 are too stiff and awkward to use (although the encoders are very good).

Overall, my over five year experience with a multitude of controllers, scripts, configs etc. drove me to this conclusion:

EVERY SOLUTION IS, SADLY, ONLY AS GOOD AS ITS WEAKEST POINT.

Many designers have some brilliant ideas, but one or two things can in practice ruin the usability of a given product. So far, every single solution I tried has some kind of a showstopper.

You seem to bo on a right way, but bear in mind, that your design needs to be *VERY good*, as *only good* is not enough. I have enough of *just good* controllers, that gather dust.

OK, now backing to your project:

1. Please, make the font in the displays AS BIG AS POSSIBLE. Otherwise I couldn't imagine using your controller in a live situation. (The current trend of putting microscoping OLEDs in synths drives me crazy.)

2. Will the encoders support acceleration?

3. I guess it'to early too say, but... will your controller be bus-powered?


Expect futher questions.

Hi Piszpan,

Thanks again for your message. I hear what you are saying about a controller being as good as the weakest link. I'll do my best to not have a weak link. That being said, in the end, if the cost is too prohibited then the whole thing fails. There is a reason why many larger companies are not doing a large number of encoders with screens on each encoder. I am making this for me, but with the kind of money I'm spending I will want to recoup it. If I don't recoup all and can only get a small batch out to recoup most, I would be satisfied, because the controller will satisfy my needs exactly, but I am looking at this as an opportunity to make something bigger and expanding it.
The good news is that I'm not a large company at the time, so the overhead is low. Therefore the returns don't need to be what a bigger company would expect or require.

1. Regarding the screen, unfortunately there are a few factors that drove the decision of the OLED size. One is to keep the controller on the smaller size. I want it to be big enough so it can do what it needs to do comfortably, but not bigger. With these many encoders and screens the size is already not super small, but not very large either. I feel that as it's currently designed, it's in a sweet spot. I understand the text being too small for some, so there will be options as far as the screens that people can select from. Also, the available OLEDs that have full color only come in certain sizes. They are not always the best proportion for this project, so I feel like I selected the largest OLED that has enough pixels to convey a lot of information without being too large.

2. I do believe they will support acceleration. I'll have to test how best to implement this smoothly as best as possible.

3. Currently I don't believe it will be bus powered only. Perhaps there might be a way to do this without the screens being turned on or them being dimmed as low as possible which might affect brightness and readability. But as per my designer, this will need more power than a USB connection can provide. You have to remember that there will be 24 encoders, each has 18 LED lights around it, and each has a roughly 1" OLED screen, and 8 buttons at the bottom that light up. So, there are more things that draw power than in most controllers.

I thank you for your questions and welcome any further ones.

Much appreciate your time.

[Piszpan]

1. Wouldn't the Maschine Mk3 approach or something like this:
https://kontroleryzm.pl/ctrl-x-kicks...trl-x-2708971/
be more cost effective? Wouldn't one or two larger screens be cheaper than 24 OLEDs?

(Hm... I guess separate OLEDs can handle text streams more easily than a large screen, which maybe would require some kind of an "OS".)

2. Acceleration is a must. A properly scaled one.

[siniarch]

Originally Posted by Piszpan

1. Wouldn't the Maschine Mk3 approach or something like this:
https://kontroleryzm.pl/ctrl-x-kicks...trl-x-2708971/
be more cost effective? Wouldn't one or two larger screens be cheaper than 24 OLEDs?

(Hm... I guess separate OLEDs can handle text streams more easily than a large screen, which maybe would require some kind of an "OS".)

2. Acceleration is a must. A properly scaled one.

I have looked at something similar and presumably it would be cheaper, but as you noted, accessing the screen might be more difficult in the software department.

In the future there might be a similar module as the one you showed. But it will most likely not have as many encoders and I will have to investigate how to make good use of the screen. For now, I just like the idea of having one screen per encoder in the same location all the time in relation to the encoder.

And got it, regarding acceleration.

[Piszpan]

I absolutely understand that designing such a controller is not an easy task.

I think that before you can sketch any knob/button/display layout you need to define the assumed workflow.

I will say this once again: The first time I will need to grab the mouse will be probably the last time I would want the controller. So...

1. Even if the controller is supposed to be fully configurable, you need to be ready for some usage scenario (at least the suggested or typical worklow). So the first question is the method of navigation and selecting a plugin. The options are:
a) First plugin on the active track
b) Seleceted plugin on the active track
c) Focused plugin (with open editor)
d) Direct access to plugins regardless of their onscreen state

Options a and b seem to be, I think, most intuitive. They require dedicated buttons to navigate between tracks. Either < > buttons or 1-8 buttons + additional buttons to change banks of tracks.

Option b requires additionally some buttons like "up" and "down" to select the desired plugin on the active track.

We also need a separate button to open/close active plugin's window on screen.

Next we need + - buttons to switch between pages (banks) of parameters, as most synths have more than 24 parameters anyway.

As we can see, the necessary navigation alone requires at least 9 buttons, regardless of buttons dedicated to switching synth/FX parameters...

[Funkybot]

Originally Posted by Piszpan

I absolutely understand that designing such a controller is not an easy task.

I think that before you can sketch any knob/button/display layout you need to define the assumed workflow.

I will say this once again: The first time I will need to grab the mouse will be probably the last time I would want the controller. So...

1. Even if the controller is supposed to be fully configurable, you need to be ready for some usage scenario (at least the suggested or typical worklow). So the first question is the method of navigation and selecting a plugin. The options are:
a) First plugin on the active track
b) Seleceted plugin on the active track
c) Focused plugin (with open editor)
d) Direct access to plugins regardless of their onscreen state

Options a and b seem to be, I think, most intuitive. They require dedicated buttons to navigate between tracks. Either < > buttons or 1-8 buttons + additional buttons to change banks of tracks.

Option b requires additionally some buttons like "up" and "down" to select the desired plugin on the active track.

We also need a separate button to open/close active plugin's window on screen.

Next we need + - buttons to switch between pages (banks) of parameters, as most synths have more than 24 parameters anyway.

As we can see, the necessary navigation alone requires at least 9 buttons, regardless of buttons dedicated to switching synth/FX parameters...

I **believe** the goal here is to make more of a "dumb box" and let users configure the usage. So there will be encoders, buttons, displays...what they do will be up to the user to define.

He already mentioned building this with CSI in mind. Using CSI, you could configure buttons for banking, track navigation, firing off Reaper actions, whatever you want! You can define the displays and mappings for each plugin. You can select tracks. You can chose to display a plugin menu for plugin selection. You can set it to operate on the selected track, or on the FocusedFX window, or by selecting the track and selecting the plugin.

If you're not familiar with CSI, I think you should definitely look into it. It's crazy what it's capable of. I think Siniarch's aim is to build something that will work very well with CSI.

[Piszpan]

Originally Posted by Funkybot

I **believe** the goal here is to make more of a "dumb box" and let users configure the usage. So there will be encoders, buttons, displays...what they do will be up to the user to define.

He already mentioned building this with CSI in mind. Using CSI, you could configure buttons for banking, track navigation, firing off Reaper actions, whatever you want! You can define the displays and mappings for each plugin. You can select tracks. You can chose to display a plugin menu for plugin selection. You can set it to operate on the selected track, or on the FocusedFX window, or by selecting the track and selecting the plugin.

If you're not familiar with CSI, I think you should definitely look into it. It's crazy what it's capable of. I think Siniarch's aim is to build something that will work very well with CSI.

Sure. But - as I pointed above - for minimum proper navigation I would require 9 buttons. Maybe 7, if only VSTi's would be taken into account. Given that the working layout shows only 8 buttons, virtually nothing is left for switching parameters.

(Of course we could switch the on/off parameters using encoders. But that's not as elegant as proper buttons.)

[Funkybot]

Originally Posted by Piszpan

Sure. But - as I pointed above - for minimum proper navigation I would require 9 buttons. Maybe 7, if only VSTi's would be taken into account. Given that the working layout shows only 8 buttons, virtually nothing is left for switching parameters.

(Of course we could switch the on/off parameters using encoders. But that's not as elegant as proper buttons.)

Here's how I'd imagine I'd integrate that into my setup...

I have a Steinberg CMC-QC as a MIDI device. That has a "Shift" button that's setup as my "Shift Modifier" in CSI. I also use it for Alt, Ctrl, Option modifiers. So 4 modifiers.

You get 24 encoder buttons in the proposed device. Assuming the device does not have any built in banking/paging...I could still select channels via Shift+EncoderPush. I'd still have spare buttons via the Alt, Ctrl, Option modifiers.

Would bank/page buttons be nice in order to change pages on the device itself? Sure. Do I need separate channel select buttons though? Nah...

I'd always favor more this, more that, but cost and design/integration are major considerations I'm sure. Very interested in seeing where all this goes.

[siniarch]

Originally Posted by Piszpan

Sure. But - as I pointed above - for minimum proper navigation I would require 9 buttons. Maybe 7, if only VSTi's would be taken into account. Given that the working layout shows only 8 buttons, virtually nothing is left for switching parameters.

(Of course we could switch the on/off parameters using encoders. But that's not as elegant as proper buttons.)

Piszpan,
Again, thanks for the input. Funkybot is correct in pointing out that with CSI things are so customizable that it will most likely fit everyone's workflow.

I do understand where you are coming from regarding 9 buttons, but unfortunately the layout is based on 8 columns and therefore, 8 buttons. In the future I could look into 16 buttons, but that will add much cost.

I think if you can visualize the idea of an encoder also being a button that could be press down as a button, but also press and twisted to make the encoder react different than just turning. Also tapping an encoder could have a different outcome than pressing down. So just with one encoder you could go left/right by twisting, up/down by pressing and twisting. pressing down like a button (or if I understand correctly, pressing down could also enter a 2nd layer to that encoder) Therefore the twist could be another Left/Right and a Press/twist in layer 2 could be different than up/down. That is just one encoder. You still have 8 buttons below and 23 other encoders. And the beauty of the OLED is that yo wouldn't have to memorize what layer you are on or what the encoder is affecting at the time. So very flexible.

I think once you grasp the concept of CSI, you can expand your mind to the possibilities that a fully customizable controller can bring.

Now that I'm thinking about it, I almost wish that I put a scribble strip above each button as well. hahahah.

Thanks everyone for all your input and thoughts.

[siniarch]

Originally Posted by Piszpan

I absolutely understand that designing such a controller is not an easy task.
The options are:
a) First plugin on the active track
b) Seleceted plugin on the active track
c) Focused plugin (with open editor)
d) Direct access to plugins regardless of their onscreen state

Options a and b seem to be, I think, most intuitive. They require dedicated buttons to navigate between tracks. Either < > buttons or 1-8 buttons + additional buttons to change banks of tracks.

Option b requires additionally some buttons like "up" and "down" to select the desired plugin on the active track.

We also need a separate button to open/close active plugin's window on screen.

Next we need + - buttons to switch between pages (banks) of parameters, as most synths have more than 24 parameters anyway.

As we can see, the necessary navigation alone requires at least 9 buttons, regardless of buttons dedicated to switching synth/FX parameters...

Button 1 - Toggle: single tract/bank 8 tracks
Button 2 - either Single track up or Bank 8 tracks up (depending on button 1 state)
Button 3 - either Single track down or Bank 8 tracks down (depending on button 2 state)
Button 4 - move 1 plugin UP
Button 5 - move 1 plugin Down
Button 6 - Toggle Active Plugin's Window on Screen on/off
Button 7 - Controller page up
Button 8 - Controller page down (if you needed button 8 for something else, button 7 could just be cycle through pages. Unless you had tons of pages, it could be quick to cycle through 4-6 pages with just one button)

This could also work with just 7 or 8 buttons.

[Piszpan]

OK, using [SHIFT] for changing banks of 8 channels seems to convince me.

Also, I'm not a fan of pressing encoders (I always fear of accidentally turning them), but this may indeed save costs and panel's real estate.

[siniarch]

Ok, quick update guys.
My developer finished designing the main board, and is sending all parts to get printed. The Encoder/OLED boards needed a quick update so he revised them.

The main board will have: 12v Power Connector / USB-B connector / RJ45 (hope to make it OCS compatible) / Micro SD (for firmware upgrades) / and On-Off switch.

I should be getting the cad files tonight and will be designing the case as soon as I can. I have a friend who will be pricing out the cases and making the first one for me. Hope we can have a test unit in less than a month.

[Funkybot]

Great news! Looking very forward to seeing it.

[cjewellstudios]

Also looking forward to it!

I'd love to love this so much I sell my twisters

[siniarch]

Originally Posted by cjewellstudios

Also looking forward to it!

I'd love to love this so much I sell my twisters

Hahaha. Awesome.

Trust me, I'm pretty excited as well. Price will of course will be the real battle in the end. That and the programming, but I think the programming can always be worked on. The price will be what it will be. Of course in mass production it will be less if we can get to that point.

But I'm looking at the big picture. This being only one module with more to come once this one is off to the races.

I'll keep my fingers crossed and will begin with the case design this weekend. My friend is sending me finish samples and thicknesses of materials we can make it out of.

I'll keep you all posted. Thank you again for your interest.

[Piszpan]

Where will be the ports placed?

[siniarch]

Originally Posted by Piszpan

Where will be the ports placed?

Hahaha. I thought someone might ask. I was initially thinking of placing them in the back. The problem with that is that some might want to use this upside down.

So, I'm thinking of placing them underneath facing the back, but if people used it upside down, they could still route the cables to face the front or sides. For some reason I didn't get the cad files just yet. So I still haven't design the case. Hoping tonight I can get to it.
The power switch is detached from the main pcb board. So that will most likely be in the back.

[Geoff Waddington]

Originally Posted by siniarch

Hahaha. I thought someone might ask. I was initially thinking of placing them in the back. The problem with that is that some might want to use this upside down.

So, I'm thinking of placing them underneath facing the back, but if people used it upside down, they could still route the cables to face the front or sides. For some reason I didn't get the cad files just yet. So I still haven't design the case. Hoping tonight I can get to it.
The power switch is detached from the main pcb board. So that will most likely be in the back.

Since you are not trying to commercialize down to the last penny, maybe mount 2 ports, one on the back and one on the front with the caveat that you can use only one at a time ?

Then you could simply wire them in parallel and have the best of both worlds

[siniarch]

Originally Posted by Geoff Waddington

Since you are not trying to commercialize down to the last penny, maybe mount 2 ports, one on the back and one on the front with the caveat that you can use only one at a time ?

Then you could simply wire them in parallel and have the best of both worlds

Maybe in the next version. Currently the main PCB does not reach from the front to the back of the unit. Any additional size and prices do go up.

[siniarch]

Hey guys,
I don't have a final price yet, as I haven't done the case, nor any of the packaging and still have to figure out shipping cost from China and any import/export fees, but it looks like it may definitely be under $1000. (that would include a small profit for me to try and recoup some money for the initial investment, but certainly not the level of profits a large corporation would make of some of their products. I'm pushing as hard as I can to keep the costs down, but at some point it looked like the hard cost may be close to 1,000, so I'm pretty happy that I can say it will be less than that.

I've order 2 units. One for my guy and one for me. He and I will work on the firmware next. He can program it and I can be testing it on my end. Looking forward to having something to show in 2-3 weeks. (but have to see how long the case will take.) I just received the Cad drawings today and unfortunately I have some projects to take care of before I can jump on this. But those are the projects paying for the prototypes, so I can't complain much.

Getting excited.

[Funkybot]

Look forward to seeing it. Particularly once you've got the prototype up and running with CSI. You should do a video once you do. Very exciting stuff.

[siniarch]

Originally Posted by Funkybot

Look forward to seeing it. Particularly once you've got the prototype up and running with CSI. You should do a video once you do. Very exciting stuff.

Yeah I'm getting pretty excited myself. I spoke to a case mnf. And the fact that I have so many holes and so many pieces that need mounting might be an issue. I need to figure out how to counteract this.

But I can't wait to have it on hand and test with CSI.

[siniarch]

Here's a little video of us working on the firmware. It's just cycling through the screens we created so far, but we'll be getting midi code out of the unit shortly and then tell it how to control the displays and such.

As soon as the firmware is programmed to be able to be upload a new firmware, I'll be receiving my unit. This way, my programmer can work on his end, and I can test on my end.

http://bit.ly/SiniCon24_Development_0002

[ivansc]

... would look great on my Xmas tree! Can`t wait to see the finished product.

[siniarch]

Originally Posted by ivansc

... would look great on my Xmas tree! Can`t wait to see the finished product.

Hahaha. Thanks for the support. I'm working hard to make this a very versatile unit that could fit almost everyone's workflow.

Getting pretty excited as we are doing the firmware right now. Soon, I'll have a prototype with me and my programmer/PCB Designer will have one as well. He'll be able to tweak the firmware while I test it on my end with REAPER.

Hoping to get it done way before Christmas btw.

[siniarch]

Ok guys,
We are heavily working on the firmware and I decided to update the screens.
There might be more in the future, but this should get us to a good place and be able to show enough information for most purposes.



I've simplified them, but I think they are cleaner and will be more intuitive to use.

[siniarch]

Not that anyone's asking, but finally getting the parts shipped to me. I'm hoping I get them in less than 2 weeks, but we'll see.

Here's an image of the parts on a temporary holding box, just for programming purposes:

[tdc]

Really exciting seeing it all come together Siniarch!

[Pompeysie]

How's the build going?

S

[siniarch]

Originally Posted by Pompeysie

How's the build going?

S

I'm getting all the pieces for one unit on Monday the 5th by DHL.(minus the case which I've decided to design and build once I have the physical pieces on hand. Just to make sure I don't screw things up)

While the parts are on route, my guy is finishing the Firmware Bootloader. The units will have a micro SD card that will allow you to upgrade the firmware without a computer or any connection. I'm hoping that will be done by the time I received them. So, I will upgrade any firmware once they get here through a special device. Once I do, I believe any more upgrades, will be done via the microSD card.

Once the bootloader is finished, he will finish the encoder firmware, then the main firmware. And finally he will work on the OLED firmware. I've prepared a 20 page document describing the 8 final screens I designed. I haven't shared it with my firmware guy because I don't want him to lose focus on the things he's doing, but as soon as he's ready for that info, It's ready for him.

While he works on all these firmware and screens info, I will be designing the case. I have been thinking about ways to not have to have 4 standoffs per encoder. 24x4= 96 standoffs + the buttons board would require another 6, and the main board another 6. That is 106 standoffs per unit. Each standoff adds price to the case, so I've been racking my brain how to do it cheaper.

I'll keep you posted.

Thanks for asking.