c0nb0x

[mario1089]

So, tell me, how much effort would it be to add a couple of variables that are only accessable/changable via conbox (if conbox finds the OS to support them)? Could be an array of, say 8 bytes, that get displayed in conbox, and get sent to xox when changed, defaulting all at zero, both in conbox and in xoxbox, so no need to read them out of the xox. Hard to do? Do you open conbox sources?

Reason:
I`m currently thinking about adding some more interesting stuff, one thing is to live-randomize accents (and slides?) by an adjustable amount (kinda "jamming") and the other one is an option to process slides optionally by sending a fast sequence (1/64; 1/128) of notes. But it`s bad having more and more strange keycommands with the actual state not visible, so putting it into conbox would be my wish..

Not sure, though, if I find enough things to optimize / outcomment to make anything possible, as currently OUT-OF-BYTES. like all of us:(

[antto]

you'll have to put a piece of code to support the MSG_OSVER serial message and reply with a unique OS ID and OS-string for your OS
then, when c0nb0x connects - it will ask your FW for MSG_OSVER and it will display the OS-string instead of the "(auto) Adafruit v1.05"
it will also store this OS ID in any .CXM files which you export from the firmware

now, for any specific behaviour and/or features - c0nb0x would have to be modified
for the variables you want to share with c0nb0x (in a similar fashion as how the Tempo variable is shared) both your firmware and c0nb0x will need to be modified

it's no problem to add more custom messages and more "known" OSes to c0nb0x, that was my whole idea about all this..
the problem is on the firmware side, because you are already struggling to fit more "features" on the small chip, and these custom messages will require some more free space

i started coding a new "Diagnostic" firmware (based on the stock firmware v1.05) with the purpose to be the first one to implement MSG_OSVER and a few custom messages for specialized comunication with c0nb0x
i didn't finish the firmware and haven't released it yet, this was my old wish from the time there were much more people here, but i was unable to make such an app at that time

c0nb0x's source code isn't very elegant, i will be a bit ashamed if anyone sees it
i'll see after i release v1.00
i wanna have one really "stable" basic version of it, before any big modifications to the source code

[mario1089]

Haha, not elegant.. Be sure I`m also not known for elegance in code. An` I don`t give much about it. I want things to work, not more.
Anyway, let`s see where this ends. Currently looking for more places to "optimize". I think keyboard mode maybe could have some less features, I only use it for tuning; but could be builders need it more often!? Then tap-tempo option may be useless anyway, as it will be never exactly right anyway!? Or not?

[antto]

tap-tempo indeed is not "vital" in any way, the x0x internal tempo is integer, and not very precise ;]
keyboard mode is useful for troubleshooting some stuff

i'm basically finished with v1.00 (i'm currently looking into a GUI-refresh-related issue which doesn't affect the app itself much) and other than that, when we get the OSX version compiled - i'll release it

[roxxx303]

tap-tempo indeed is not "vital" in any way, the x0x internal tempo is integer, and not very precise ;]
keyboard mode is useful for troubleshooting some stuff

i'm basically finished with v1.00 (i'm currently looking into a GUI-refresh-related issue which doesn't affect the app itself much) and other than that, when we get the OSX version compiled - i'll release it

hi antto,

your link to v1 from the marOS-thread doesn't work anymore. Please post a new v1 because v099 is dangerous (overwrites Bootloader if x0x-OS is too big). This is a very serious bug!

Thanks!

[antto]

yes, i intentionally removed the file
v1.00 would be up today or tomorrow (if nothing goes wrong)

[mario1089]

antto,
for MarOS1.2, I have added an addtinional message for sending and recieving in compcontrol.h/c. It sends / recieves 5 bytes, each representing one parameter of my heavily modified sequencer. What can I do to make conbox show the values and make them adjustable from there? Is it enough for conbox to detect MarOS1.2 by asking for that MSG (and get back bytes of expected size)? Will you take care? Or send me the related files, and I add the code? Thanx either ways:)

[antto]

to implement MSG_FW_VER add this to compcontrol.c:

Code: Select all

            case MSG_FW_VER:
            {
               //  2bytes    2bytes   <variable>
               // [ osID ] [ osVER ] [ os string ]
               // os string should not be longer than 32 chars
               {
                  //uint16_t* ptr = reinterpret_cast<uint16_t*>(&(tx_msg_buff[3]));
                  uint16_t* ptr = (uint16_t*)(tx_msg_buff+3);
                  *ptr = 101; // osID
                  ++ptr;
                  *ptr = 101; // version 1.01
               }
               // this packet is 4 + 4 + 6 bytes = 14
               unsigned char* ptr = (tx_msg_buff+(3+4));
               //*ptr = { 'd', 'i', 'a', 'g', 'O', 'S' };
               for (uint8_t i = 0; i < 6; i++)
               {
                  ptr[i] = "diagOS"[i];
               }
                    tx_msg_buff[0] = MSG_FW_VER;
                    tx_msg_buff[1] = 0;
                    tx_msg_buff[2] = 10;
               tx_msg_buff[3+10] = calc_CRC8(tx_msg_buff, 3+10);
               send_msg(tx_msg_buff, 4+10);
               
            } break;


change "diagOS" to whatever you like (it will be shown in c0nb0x in computer control mode
change also the version - 100 will be shown as "v1.00" in c0nb0x
change the OSID which is the most important thing to c0nb0x, as it doesn't care about the string
this whould be unique, see below

in compcontrol.h

Code: Select all

enum SERIALMSG
{
   MSG_UNUSED      = 0,    // 0x00 c0nb0x specific, not used by adafruit or sokkos
   MSG_PING      = 1,   // 0x01
   MSG_PATT_WR      = 16,   // 0x10
   MSG_PATT_RD      = 17,   // 0x11
   MSG_PATT_LOAD   = 18,   // 0x12
   MSG_PATT_GET   = 19,   // 0x13
   MSG_PATT_PLAY   = 20,   // 0x14
   MSG_PATT_STOP   = 21,   // 0x15
   MSG_PATT      = 25,   // 0x19
   MSG_TRACK_WR   = 32,   // 0x20
   MSG_TRACK_RD   = 33,   // 0x21
   MSG_TRACK_LOAD   = 34,   // 0x22
   MSG_TRACK_GET   = 35,   // 0x23
   MSG_TRACK      = 41,   // 0x29
   MSG_SEQ_START   = 48,   // 0x30
   MSG_SEQ_STOP   = 49,   // 0x31
   MSG_SEQ_GET      = 50,   // 0x32
   MSG_SYNC_SET   = 51,   // 0x33
   MSG_TEMPO_GET   = 64,   // 0x40
   MSG_TEMPO_SET   = 65,   // 0x41
   MSG_TEMPO      = 66,   // 0x42
   MSG_STATUS      = 128,   // 0x80
   // /---------------------------
   //  extended messages go here (after 128)
   // ---------------------------/
   MSG_FW_VER      = 129,  // 0x81
   MSG_ISSUPP      = 130,  // 0x82 "is MSG supported"
   MSG_DIAG        = 131,  // 0x83 all diagnostic stuff will be sub-messages, so i don't waste the numbers here
};

enum STATREPLY
{
    STAT_BAD    = 0,
    STAT_OK     = 1,
    // ------------------
    // EXTENDED go here after 1
    // ------------------
    STAT_NOTSUP = 3,    // "not supported request/feature"
    STAT_SUPP   = 4,    // "supported"
};


OSID: this is mostly important if c0nb0x must have some unique behaviour depending on a given firmware
here are examples:
- if pattern format is different than the stock format (for example n0nx0x which uses 21 bytes, and sokkos 2 which has triplet)
- if there are unique messages for that OS (for example diagOS has a special message designed for reporting buttons and other stuff)

here are the OSIDs currently known to c0nb0x:

Code: Select all

enum X0X_OSID
{
    OSID_UNKNOWN    = 0, // unknown, adafruit v1.05 compatible
    OSID_ADA105     = 1,
    OSID_N0NX0XBETA = 13,
    OSID_DIAGFW     = 101, // hehe
};


note: n0nx0x itself doesn't implement these new messages (since i wrote it long before c0nb0x) but c0nb0x autodetects it via patternsize=21

so, if you want to implement MSG_FW_VER - pitck a value which isn't already in this list

now, for actual special behaviour of c0nb0x..
your request about showing a few values and being able to automatically update their values (in the app) and also change them via the app.. this is a common thing to digital instruments

you know you can implement these as MIDI CC probably
but besides that, i still see a point about making it exclusive to the app
so here's what i think
first, when c0nb0x connects to the x0x - it already performs a few tests to figure out what the firmware is, and what can it do..
that's where MSG_ISSUPP comes in, with it, c0nb0x can ask the OS if it supports this or that
currently, it hasn't been implemented yet, but the packet structure is known

so, the OS would be asked if it supports "PARAMS" and will return either a status STAT_BAD or a special message MSG_PARAMS with a number - the number of parameters it has
this is so that c0nb0x can (for example) make a list of these params later

now, when any of those params are changed from the OS - a message will have to be sent - MSG_PARAM_CHANGED holding the param index and it's value
i think the param value would be held in an uint8_t

i'm also thinking there should be a way to make some params have a specific number of options, it gets a bit complicated here but don't worry now

see, this then won't be exclusive to your OS, but a standard functionality for any OS which implements the mechanism, and thus, you would be able to change the number of params and their meaning from your OS without having to modify c0nb0x every time

i don't want to delay v1.00 because of these things, as i mentioned, i want to release a stable basic version ASAP and then i'll clean up the code a bit and probably revisit diagOS, and these new messages and features

[antto]

you might have noticed that somehow i am not very enthusiastic about all this, compared to the amount of enthusiasm i had initially

the idea about me making a x0xb0x control app was born around the time when we were talking about a CPU modification and i also had severe problems with my own firmware and c0ntr0l
since a new CPU would require some slight modifications of the stock firmware, and wouldn't be compatible with the existing c0ntr0l app - this was the ideal moment for a new serial protocol to be made up, and many messages could have been added since there would have been 256kB flash memory for an OS
(this all means that c0nb0x probably would have been specifically designed for the CPU-modified x0xb0x, and standard x0xes would have had to use c0ntr0l only)

later, something happened, and the CPU mod project got paused for a long time
afterwards it got dead
when i really started coding c0nb0x - i already knew the CPU mod is not going to see the light of day, which breaks my heart because i really wanted this thing

so today.. i still remember my passion and everything i wanted to put into c0nb0x and the CPU mod..
but, there's no CPU mod, and as you can see, you are struggling to fit a handful of features
adding additional messages to c0nb0x is easy, adding the mechanisms for them in the OS is not easy when you've already deleted most features and are hitting the 16kB limit

..so that's why..

[mario1089]

yep, antto, I see.. Was reading the new CPU thread last night. Must have been a disappointing time, you guys starting with all that enthusiasm, and then seeing it somehow dying. I was on textile`s site last night (http://somaticcircuits.net), seeing him offering the daughther board with firmware (!! - who changed the code to match the new adresses?) in NEWS OF NOVEMBER 2012. Does that mean anything?

Anyways, about my requests for conbox. It`s a nice idea to support paramters for any other firmware in a generic way, and easy to do, but unfort. it`s kinda impossible. It means the firmware (!) has to tell conbox 1) at least: the name of any of the params, 2) how to calculate the real value into something user-readable 3) the range allowed to be used. I know there is some other concepts how to do this, like all params normalized, but then the firmware has to convert back and forth. And the name always has to be sent. All of that is impossible for me with just a handful of bytes left, everything already pretty optimized and actually still a wish list (mostly: fine-swing to proper DINSync - for the hardware guys).

So if you`re not so ethusiastic about this, which I can understand, why not just giving me the sources after stable 1.0 is released - so then I add my stuff and release the conbox.exe together with the MarOS? I mean it`s not life or death for me, it`s a little bit about the fun of playing around with some code, that`s not so ridiciously complex like what I have to do during the weeks..

[antto]

OMG, his website is up \o/

mario1089: the parameter names and how they should be displayed in c0nb0x - this would be sent only once on init (aka when c0nb0x first connects)
afterwards the OS will only send param update messages, which will only contain the raw param value and it's index
any kind of convertion will be done in the app
it's not so bad
but it's still not as good as it can be, any additional line of code takes up space usually

that's why we wanted this cpu mod so badly
and now, it seems it has resurected
there is HOPE again

[roxxx303]

Hi antto,

yesterday I tried c0nb0x for the first time! And it worked like a charme!
Never tried it before because it looked so command-line-style.
But it has menues and is simple to use. Cool!
The only thing I miss in pattern-edit-mode is some cool randomize-functions.
Perhaps it is a cool idea to implement the random-algorythms of marOS in c0nb0x! (And mario perhaps will assist )
I would prefer to have it in a control software than in OS, because I am happy with sokos and don't want to mess up my x0x
(I never tried if the updater of the OS works on my x0x!).

I am a x0xb0x-user for only one year now and I totally missed the early-pioneer-years of the x0xb0x-project at all.
Always loved the 303 and bought a novation-bass-station back in the mid-90ties and then rebirth.
Over the years I lost interest in the 303 because it was overused and with rebirth and abl everyone could use it.
But two years ago I remembered my old love (tb-303) and I wanted to have a real hardware-clone
because the prices for 303 never really went down (I waited for it over all the years).
Sadly I did not buy the 303 which was offered to me in 1992 for 250 Euros - I was still not ready for it at that time and bought an alfa-juno for the money...
Then I found the existance of the x0x and contacted substyler to build a custom x0x which I got last year.
I really love it but my wish for the "real thing" was still unsatisfied till I bought a tb-303 in june of this year.
Now I have both and love both!
And though I love the warm, analog sound of my "real" I prefer working with the x0x. It has so many advantages, is so great to use with midi and a DAW and to backup patterns and it even has more bite with full resonance (And an integrated overdrive)!
The only thing which I love more on the tb is the creation of random-patterns!
I never have batteries in my tb. And everytime I start it, it is full of crazy, funky Random-Patterns.
The coolest are non 16 beats!
The best ones I write down and programm it to my x0x to back it up and use it for new songs.

But last year when I got the x0x, in the adafruit-forum it was very quite and I had the feeling everything has
happened without me and the x0x-enthusiasm is over now!
So now I am happy that a new enthusiasm is born from new users like mario which are full of fresh ideas and use the open-source of the x0x to build a new OS. Also c0nb0x is a much better tool than c0ntr0l - it only lacks random-mode(s)!

Keep the acid-spirit alive!
-roxxx303

[antto]

in v1.00 there are already a few basic pattern manipulators - shift, reorder
i know how to write more advanced manipulators but c0nb0x's pattern editor only deals with 1 pattern at a time
it's much more interesting in a 303-style sequencer with chains of patterns

good news for you and your 303, you can directly write the patterns from your 303 into c0nb0x's pattern editor, since it uses 303-pattern notation (sepparate pitch and time info)
in v1.00 writing patterns is easy now, since there are hotkeys with auto-advance

i'll probably add a simple randomizer

[roxxx303]

in v1.00 there are already a few basic pattern manipulators - shift, reorder
i know how to write more advanced manipulators but c0nb0x's pattern editor only deals with 1 pattern at a time
it's much more interesting in a 303-style sequencer with chains of patterns

a la Box Energie ?

good news for you and your 303, you can directly write the patterns from your 303 into c0nb0x's pattern editor, since it uses 303-pattern notation (sepparate pitch and time info)
in v1.00 writing patterns is easy now, since there are hotkeys with auto-advance

Really good news!
And hotkeys with auto-advance sounds good!

i'll probably add a simple randomizer

Please make it happen, make it real!
- Today!

-roxxx303

[antto]

i'm currently uploading (trying to, since my internet connection is pretty broken) the win32 version
so, randomizer would have to be in a next version (which could be quite soon too)

btw, the reorder function is very useful, it takes all the existing data and randomly re-orders it