This N°9

just contact smashTV directly, I'am sure he will help you. Or build it on your own. Starting with kits has the advantage that you can concentrate on what you want to do with it rather than building the PCB, testing and troubleshooting it etcetc. But of course it's also fun to build all from ground up, this gives some extra experience and knowledge..

I post here the zip package for my MIDI-Mapper application. I don't know exactly what to do with the release package. Could somebody put this to it's new home and post me the link? documentation is almost finished. I will add a PDF usage manual: http://www.midibox.org/dokuwiki/home:project:midi_mapper thanks midi_mapper_dist.zip midi_mapper_dist.zip

hm.. maybe this would be a good way to get into the whole MIOS32 story.. I guess there are bulk orders running? My last impression when I stook my nose into the MIOS32/MBHP32 threads was, that stuff is almost ready to takeoff? this is also true... and I have some already built core modules left. When I get stuff running on a slower smaller core, this has no disadvantage. The speed of the MIDI-transmission itself stays the same for both..and if I run into the wall, it's no big thing to port the application for the new core module (which will be a good idea anyway). hmm.. maybe. I think I'll check both variants anyway. Of course theres no speed advantage in using the IC's, and I'm not sure if they have life extending stuff built in, but maybe someday somebody for any curious reason prefers a IC. I'll stick my nose a bit inside your SD card code, learn some ASM, I think it would not be a big thing to port the code for the Spansion.

that's exactly what you do when you buy from smashTV. you buy a "Kit", that means the printed board, all the parts you need and the PIC with the bootloader. The price is very modest, I doubt that you will get all this cheaper if you buy it separate (and you will save the time to search all the stuff). Mind that smashTV can buy the parts in bigger amounts, therefore cheaper (?). a complete core-kit with PIC costs $26.95 @ smashTV, I think this is a very ok price. check it out: http://www.avishowtech.com/mbhp/buy.html you can also buy just the PCB without the parts. but as said I doubt that this will save you anything (time/money/nerves)

I saw that with FAT I can't append data to files. Thats bad, maybe I will build my own little FS with just numbered files, that would save me quite some memory for buffering etc. The concept for the FS is already worked out (originally for Banksticks), I just have to alter the blocksize. No more chipselect, this is nice also. I just ordered some SD cards, slots for them, and also some serial flash IC's that I mentioned above, I think they should work with the SD driver also? they support clock frequency up to 50MHz, and use SPI as protocol. I will check what I will use in the end, maybe I'll use the IC's, when I use my own FS, then I have no advantage to plug it in and out. If the memory is dead, I have to open the box and change the chip, but I think it will last some years.. I think a sysex-backup will do it also. UPATE: the Spansions IC's use a different command set than SD-cards.

actually I ordered all the stuff from smashTV.. For the banksticks, you will pay quite more in europe than @ smashTV, if you order not just one or so, this counts.. the ribbon cables are quite common, also the plugs. check http://conrad.com/ or https://www.distrelec.ch/ishop/StaticHTML/shared/distrelec/ or http://www.reichelt.de/ .. also http://farnell.ch/ has a lot of stuff. I just ordered some flash-memory stuff there.

I just setup a test - board with a core,LCD 4 encoders, 32 buttons , 32 LED's 2 DIN modules, 2 DOUT modules. This is my "midibox-test-suite". You ever played with LEGO ? :-)

The seqencer's target is not so much to play arround with the speed of a single clip. maybe you could double/half the speed or so. even if there is a pause of say 19 ticks, and I can't half this, there is still the fixed length of the clip itself, that ensures that it will be triggered at the right point in time again. But this is a good point, maybe I would have to keep track of the clips last starting point. About memory consuption: I'll limit the clips playing back at once to 16, I think for my needs this is enough (1 bassline, 1 harmony part, 1 melody part, drum part, effects part, ....., ...., ....). So I'll have a struct for each playing clip, maybe - current pointer in file - next event playback time - last clip start time if each of these values is a int, I need 16x6 = 96 bytes. for recording (only one clip at one time) I need a buffer of 256 bytes as a global counter, a int (max pause length is 2048 quarter notes then, taking overflow into account). another challenge will be the playback streaming. without any buffer, in worst case I have to read 16 blocks, each takes 3ms to read, so this ends up 48ms just for read delays. this would be too much if my ticks are ca. 30ms for 120BPM. So maybe a playback buffer would be usefull, say 128bytes and a smart buffering concept. this would end up in ca. 500 bytes memory needed for the app. I hope this fits, taking the memory consumption of the FAT driver and MIOS in account... If not, I may need 2 or more cores, one just as a "file-server" or so...

I wont do that. Just one counter for all clips. Increasing speed for a single clip would mean to modifiy all "pauses" accordingly, e.g. double/half them. what's the vX?

@TK very nice, the SD card stuff! I think this perfectly servers my needs.

..a future project could be a sampler based on a pico ITX board and a linux with a dedicated app. The device could be used independently just as a sampler or with the sequencers communication over MIDI with dedicated commands, so also audio clips could be recorded/played back by the seqeuncer. A challenge would be to implement the time-streting algorithms, but I think there will be some ready-to-use code examples arround I hope.

why I want to build a thing like this: I was always looking for a ableton-live-style sequencer, but this simply doesnt exist on the market. I dont want to use a personal computer for music, I sit in front of a monitor all day, and I want to have a more dedicated device with the proper buttons etc. I shopped a MV-8000 by roland, which is really a very powerfull and nice device for composing, a dream machine, you can even put it in sampler mode, if you do so, you can access all parts(instruments) on it in parallel by midi. Then I have a paia modular system for bass sounds etc. and a muse research receptor for VST plugins. My way of composing usually goes like this: I have some idea for harmonies or a bassline, I want to play it on the masterkeyboard and record it as quick as possible. I can do this with the MV, but I first have to setup a new song, select the channel for the track etc. This takes too long. Besides the MV's live jamming features are limited, it's more a composing tool than a live tool. So I need a machine that uses exactly the principle that ableton live does, you can trigger clips in any combination you want. Here the target features of the machine: - 16 vertical "strips" each one targeting a midi-channel. - each strip has 8 or more buttons for clips. eventually I will implement a paging, so you can have more clips. - each clip has a length, can be one-shot or loop - for each strip, one clip can play at one time - one clip can be recorded at one time, by simply hold the record button and push the clip. record modes are overdub/replace, I would like to have the replace mode only replace until you played the last note, so in fact the last "take" will last. - max. resolution will be 1/128, this gives me 30ms@120BPM / 15ms@240BPM to stream data from/to the storage in realtime, which would be even enough with a bankstick as storage. With a flash, this would be even better. - one you have some clips playing, you can store this as a "scene" or whatever it's called. Scenes work like clips, you can push the scene button, and the clips start to play. Then you can play arround again. - a song is just a set of clips and scenes. should be no problem. Between the single MIDI events I will place "spacer" events, they just hold the number of "ticks" to wait until the next event. I align this to a global counter, that is driven by a timer or external MIDI-clock. I'll have to handle counter overflow somehow. If you change playback speed, the only thing that happens is the counter increase speed. The first challenge is just to build the app for a single clip. Then "clone" the clips and check if the core can handle this.

hi, I was looking for storage which could be used with MIDI-box. My target is to build a non-step sequencer (clip based, like ableton live) and need non-volatile storage that is fast enough to read/write MIDI-streams realtime. First I planed to use banksticks and use RC4/RC5 pins to multiplex, so I could access 4x8 banksticks, I would have 2 MBytes of storage available (32x64KBytes). My plan is to write a very simple filesystem, that allows me to handle clips with variable size. About speed: The 24LC512 datasheet says, that a write cycle (64bytes or one byte) takes max 5ms. This is quite much but would be fast enough if I reduce the sequencers' maximal resolution to 1/128 rather than 1/384 (MIDI clock). With 120 BPM one "step" would be ca. 30ms, this is enough to play back and eventually write 64bytes of data to the bankstick. When I was looking for alternatives for the bankstick concept, I found this part: http://www.spansion.com/products/S25FL016A.html It looks quite interesting, it's fast (256 bytes in 1.5ms), even 64Mbit/128Mbit is available for a good price: http://at.farnell.com/jsp/search/browse.jsp;jsessionid=R4ZQVHLMSR2AOCQLCISZKBQ?N=0&Ntk=gensearch_002&Ntt=S25FL&Ntx=&_requestid=233886 maybe this is interesting for somebody else, I will check out a bit more. This would save me from having 32 IC's for my storage, and save some time for the writes.

I agree. I like the new layout better. And the source code is easier to edit.

@durisian: I see you changed the home:project to the old layout. Why that?

wow, this looks really nice.. I like those purist designs.

aehm.. explain that to me. I usualy buy the parts somewhere.. do you design knobs/buttons etc? If yes, this could be a very interesting thing.

they are up. don't need root/community/this* no more I agree with that too. It would end up in creating more and more namespaces. The projects can be grouped on a page where they are linked, and I think there's not really a need to reflect the SVN-directory structure in the wiki's project-pages. The basic concept for now is to have just two top-level namespaces, 'home' for all midibox- and midibox-related info, and wikify for info about how to edit the wiki. If there should be a misc namespace, I think it should be a sub of home. This is a danger if the namespace is once there. I think a misc namespace should only be created if there is one day really no place to put in a page. It's better to create new namespaces if needed that are more specific like 'electronics' or 'related products' etc.

for me 'wikify:template:home' would be the logical place to put it. (also for the other ones, like: 'wikify:template:home:about'). what do you think? could also be flat ('wikify:template:home', 'wikify:template:about', 'wikify:template:project', 'wikify:template:module'). general question: is it really necessary to keep all these templates? maybe just some of them, or additionally a 'general style principels' page would do it, something like a styleguide page. hmm.. I don't know. The new wiki would be linked to the one that is live, say a project-page is linked from the old wiki, on this page then you have links to modules etc., maybe you will land on pages that are not finished etc. I know, some projects (mine as well) in the new wiki are already linked on the old projects page, but if I think about it again, it's maybe not a wise thing to do.. This again would be a good argument for "cut/paste" instead of "copy/paste" old pages. One alternative would be to add comments in the source code of the old pages that will not be visible on the rendered page, like "all info on this page was totally moved etc..". The problem about this would be, that new info could go to pages, that are already marked as "done", so maybe stryd's proposition is the best solution.

@stry_one: I think this is just a missunderstanding: I just realised, that the namespaces in the filemanager are the same as the ones of the pages.. :D so it's just about removing the :root: namespace one day, I think this one will not be used. I'll upload the files for the midi_mapper just to :home:project:misc:midi_mapper. I think now I also understand what you tried to tell me earlier in this thread about the namespaces and users (:home:community:xx...) everything fine, thank you!

@stryd_one did it.. :). thanks for your trust in fact all the content from new_wiki_layout is copied (and modified) to home:* now. I tried to fix some links and tidy up the namespace concept at some points: -home --about ---faq ----xxx (if needed) ---midibox (What is a MIDIbox) ---ucapps (Introduction to uCApps.de) ---mbhp_acronyms (MBHP Acronyms) and.. skills namespace prepared (links on the pages). So now the whole stuff can be built upon the existing pages. If somebody feels that we are doing crap, just make an intervention. I think the namespace-concept is quite tight now, and can serve as a solid base. of course it can always be expanded, or pages can be moved if required.

I propose a litte modification: [[:home:troubleshooting:home]] [[:home:troubleshooting]] //entry page for troubleshooting. all the other troubleshooting pages are linked there same for skills. skills - entrypage links to sub-pages. maybe the skills entry-page could be linked on the project page then, instead of multiple skills-pages.

agree to that. the links will be in the module/project template already prepared, so this takes no extra time when adding a new page. All the links in the template should be updated accordingly then. I like your spirit Just Phil. I think you are the right man to the right time ;)

I like just phildurisian's proposition. one question is if parts should be in mbhp, but I think it's the right place. sorry for my short absence, my internet connection is currently very weak, maybe somebody is standing on a cable somewhere.. I come to chat.

hm.. wiki is on top, some thoughts seem to reach multiple brains at once.. @durisian: I just started a thread before I read your post: http://www.midibox.org/forum/index.php/topic,12558.0.html I suggest to continue the discussion there