stryd_one

Hi, welcome aboard! It's in the correct forum... Why email? Can't we chat here, that's what the forum is for! You should read the ucapps link at the to of the page, especially look at the C programming examples. You will see that making a MIDIbox do your desired task, is about 2 lines of code :)

Personally, I am a fan of the good old JDM. It will only work on motherboards which have a REAL com port though, so some people have troubles.... But it's a very simple build. As for the mbhp Burner, I would just use a normal wall-wart supply.

Hmmm.... Which application are you trying to build?

What are you making? Did you download a new zip file from ucapps.de recently?

this is one of those everlasting threads, additions are welcome/encouraged :)

Try the other stuff i mentioned first, as it's quite possibly a browser error (Usually is) Anyway, I know that for example /tilted/ had trouble logging in, because of the non-alpha characters. If you are convinced that is the problem, then you can't fix it by changing your name on the forum, because that is only the display name, and does not change your account name - it's only changing what gets shown in the left hand column here.... Send Twin-X a PM to ask him to rename your account to "schmoker".

You found it gein? :) Smithy: no need to lock down. It's a wiki, unwanted changes can be reverted. Given that the ucapps site is on SVN, it's already openly modifiable... same though, unwanted changes will be reverted.

Don't tease us ;)

I guess you use the same username/password combination to log into the wiki, as you use on the forum? Are you blocking a cookie? That would break it.... Maybe you need to clear the cookies and restart your browser before you try again...Perhaps the special character in your username is making troubles... Yes, all the MIOS apps will continue to be "supported"* after the new hardware release. MIOS32 is overkill for most applications. In the private forum TK made it clear that this is definitely NOT a "bin your old stuff" moment. * Ultra kinda said it all about "supported". Nothing here is really officially supported, but you know the kind of support that occurs, regardless. If people are using it, people can (and usually will) help. If you find a bug, TK or others can (and usually will, if it's possible) fix it.... It's all good :)

Heh, exactly. OT Yes I do think a search box for ucapps.de would be nice. You can use google to restrict the search to ucapps.de now, but a button would be good. Two issues with that - one, there aren't that many pages, if you need to search you probably didn't browse enough ;) Two, TK has often spoken of migrating the ucapps doco to the wiki, as new wiki pages are created which include/replace the info on ucapps. We just need more doco volunteers.

1) That's GUISIM Specific, not sure there. 2) Use the instructions on the wiki for setting up a custom makefile 3) Huh? Code, please :) Whether you run make (you don't run SDCC, the makefile does that) from codeblocks or the command line makes no difference. It's still make and it's still the same code...

Search, RTFM.

Good call dude, you won't be disappointed.

Good luck! :)

That's a great idea!

I'll quit building that sequencer when I quit making music, which will be when I quit breathing ;) It never stops, I write new code on it at least once per week as a rule.... just sometimes it moves so slowly that people *think* it's dead/vapour. It's not, it's just not publicly available :)

Well if you wanted that, you could have swapped reaktor for max, and exported the instruments as VSTi ;) Sadly yes. Probably not as much profit involved in such a thing....

Welcome aboard! If you have chosen to experiment, rather than purchasing the encoder specified in the design, I would suggest that you do just that - experiment. Try them, and see how it goes. If you haven't ordered yet. you are looking at the wrong part. Check the parts list!

Oh.... If someone else wants to have a shot at it, I'm sure you could do with with a current MBHP core by modifying one of the existing apps like toolbox or MBCV...

hah, no so much "secret" as "poorly documented"... my bad! You might have heard about the vX sequencer, this is an evolution of that. Or rather, a de-devolution of it - I got some extra power from the new core, so I can bring back all the stuff I had to remove to make it work on a PIC. The short version: You have a virtual rack in which you can dynamically insert or remove virtual modules. The modules (yes you can code your own, and add them into the project) have a number (any number <127, defined as part of the module's design) of 'ports'. They'd be the equivalent of the jacks in an analog module, but you can read or write them (they're outputs and inputs, simultaneously). You can patch the modules together, from any port to another. When a module's port(s) is updated, it runs a processing function (that's the 'guts' off the module design). That function should update ports which are intended as outputs. it's pre-processing, essentially. Modules carry a timestamp which they can set themselves (say, by reading a clock module for the timestamp when it will tick next). Each time the MIDI clock (at 384ppqn) ticks, each modules timestamp is checked, and when this timestamp matches the time 'now', then the module is marked as 'ticked' and the processing function is called. The 'outputs' of the module should already be pre-processed at this stage - they are ready to be sent immediately. This allows the processing function to quickly fill a buffer (each module has it's own buffer) with outgoing data. once all modules have done this, the buffers are sent using an output type (also extendable by coding your own) like MIDI or OSC or AOUT or whatever. Sequencer/LFO/etc modules do not hold their own note data; rather, the data is stored separately in a 'pattern' (just an array of chars). Each pattern is like a 'layer' in MBseq, and can be shared with as many modules as you like. So for example if you have a pattern full of 0x7f, you can use it for all your modules where you want to send full velocity. Or you can have a pattern which you can use as a 'gate' for various modules, so in effect, you can store rhythms independent of harmonies. blah blah blah. The long version is coming, when I finalise a few things .... i'm working on making the ports cross-compatible with all port types, like clock signals (32bit timestamps), analog voltage-style variables (8bit vars, like a midi note number for example), analog gate-style messages (1 bit, like an accent on a seq), etc). I do have some "examples", but they are very basic (enough to show that the code works and is performant). It's not at a stage where I'm willing to share it publicly yet, but as mios32 development progresses I will post updates.

Error message? Were you logged in? It's offtopic in here, but of course it will. That's like saying " I hope XP does'nt make win2k obsolete" :) What are you worried about anyway? If v3 does everything you need, you can always make a v3...

ultra's protocol is higher level than that. It would sit in the layer atop OSC, or in this case, MIDI. Same concept as Mackie/LC.

I dunno... even if the synths only have one accent input, multiple accent/slide/whatever tracks can still be useful. You just have to have a way to mix them (XOR for example)

It's a test, you don't succeed or fail, you do it, and post the results ;) You should be testing the voltages at all points in the signal path, when you run that SRIO test - at the core, and at each DIN module, on both sides, and where those traces meet the IC's, etc. That says your core is working, at least to some extent :) I think I'm not psychic... got a link to these diagrams?

If you write a digipot driver, it should be implemented as another type of AOUT module. Then you can use the patch structure's existing stuff space, and you're in business. So, no need for any mods to MB6582, just write a digipot driver.