moogah

Thats some good stuff right there man, congrats!

I'll get a specific measure of the tempo change next time I'm at the bench, but it is unmistakeable-watching the Tempo indicator and the GP LED's it is clear that the tempo drops from ~120 to ~60. In fact it is quite possible that the tempo is 'saturating' to it's minimum value. Heh.. not sure 'saturation' and 'minimum' are the proper match, but it's all I can think of at the moment :)

Again, you need to do some more reading and building before you commit to doing such a large project for school. the Digital INput module is the *only* way to hook up inputs, and you probably don't need 2 cores, not right away. The MB64e application is what you are going to base this project on, adapting the midi messages sent to control Abelton. There are many other people who have done this, keep reading and give yourself *plenty* of time to digest the information. Your really jumping the gun a bit :) I don't want to discourage you, but it is somewhat unreasonable to expect someone to absorb the amount of information around here in a couple months. I would strongly reccomend building a simple MB first, then think about how to make a custom one. Start with just 16 buttons and 16 encoders (one DIN board). What is your level of technical expirience? Programming? Electronics? Soldering?

Woa. Backup a bit man. It sounds like you may have made a major commitment without fully understanding what your getting into. You need to have a much better idea about how to make a MIDIBox before you decide to get graded on it ;) The questions you've asked are all answered in the regular documentation to your left. This isn't something you are likely to finish in a couple months, so I would strongly reccomend you do something else for school, and continue here as a hobby, build at least one of the standard MB devices first, then work on a custom unit.

Sure, here is the schem I've been using for the 808. It is not a complete copy of the Core, some of the headers are not present. What is there has been tested tho. I had to rename the extension to .txt to get it to upload, which apparanlty screws eagle up. I can't upload .zip files either, can an admin allow the .zip, .sch, .lbr, .brd files to be uploaded? I've got some eagle libraries I'd like to share too.

Alright, finally got around to doing some more testing tonight. The problem with the tempo dropping when drums_init.syx is edited happens with the unmodified source as well (taken right out of the .zip file). At the moment I don't have any pointers to give on what may be causing it, but I'm looking at a possible mistake with the layout as that is the only X factor between this SEQ and any other one. Perhaps someone can upload the file to their SEQ to test this? All you have to do is change the first "3E" to "3F".. or "2A" or anything, I've found that any change to the data will produce the result. It's also possible that I've been careless while editing and somehow there is something akin to a checksum error that is causing the problem. Work has been slow going lately as classes have started, but I will report back as I get more information.

Yes, for our purposes all the suffix's work the same. Get the cheap ones. Can you give me a link to the spec sheet for "HC49"? I'm not familiar with it. The circuit will prolly still work just fine, but you may have trouble stuffing the board. Yes, polyester is a higher quality cap. Higher quality than you need, so don't buy more for this purpose. Sounds like a brand name. Your guess is as good as mine, google around a bit.

Well, the biggest thing for doing this is practice. Your first few on stripboard are pretty much guarenteed to be ugly, which probably won't affect how they work. As time goes on you'll find that you can isolate segments of the circuit mentally and organize the components accordingly. Alot of times you can roughly follow the schematic itself to start with. I find that it can help not to solder anything in untill I've stuffed the board and taken a good look at it. With a PSU you want to be sure that the path to ground for each component does not travel through another component. Following a well layed out schem can be helpful for this too.

Trigger voltages are 5v. The 808 itself uses a 5-15v pulse for the accent signal. I don't have anything to test with, but it is my assumption that you can just tap the 5v pulse for trigger. I've got a header on the board for doing this, and there is a simple buffer there to drive a LED which I'm pretty sure can do double duty. Check out the WIKI page, I've got a description of how it all works there.. just text tho so it may be rough to read..

Time to finish my .02 I had to stop and re-read this thread along with the WIKI page before giving my input as things have changed a bit since I last read. So far I agree with just about everything people have said in this thread, even the stuff everybody agrees isn't part of a TR sequencer. So, alot of this will be redundant, but I'm including a complete picture of my ideal TR: -Standard 16 step editing: We all know what this means. And I feel the need to stress that adding more buttons to allow 32 editable steps is not a strict benefit. It makes the interface more crowded and less easy to read. I do like the idea of having greater scope for editing patterns tho, and I like the idea of two rows of different size buttons. One could display current track and the other the instrument data or similar. That would be pretty useful. The software should be able to scale the number of buttons so that people can use as many as they want. -Instant hands on control of all parameteters, accessable in any mode of the instrument. Despite what I'm doing for the 808 I think the best idea is to give every function it's own button. Menus are not good for jamming. Encoders don't "play" well IMO. Buttons and toggle switches make the 808 great. Even so I would generally stick to displaying one bar at a time, thats just me tho :) -"Transparent" song mode. Pattern play mode is good for jamming, but often falls short for complex sequences (you won't always have free hands). Song mode on the other hand is usually too rigid for me. I would propose wrapping pattern play mode inside song mode so that you still have total freedom to move around while the song is playing, and songmode will still be sure you make that tricky fill in to chorus part while you tweak the freq on another synth. -"Transparent" edit mode. I don't ever want to press the stop button. Seriously. I should be able to go and edit a song while it is playing, and edit a pattern while the song is playing. -Pattern chaining need to be as simple and powerful as possible, all done on the fly without menus and encoders. -Lots of syncronization options, in and out. MIDI, DIN, individual triggers per instrument, clock trigger. Everything. -Global accent and individual accent per instrument. -Flam, implemented like the 909 -Swing -Variations and Fill patterns. This is the main reason I want song mode to be transparent. Now, how many features have been suggested that are not already in the V2 application, or in the V3 wishlist? From working on my own version I've found that *everything* on my list of features was already implemented in the SEQ, it is just a matter of mapping the features to controls the way I like.

It's probably about time I dropped in here :) Damn-Skippity-Straight it is! Even more than the sound, I remember that feature most fondly. While I was working on the clone I had originally tried to find similar 3 way toggle switches (A, A+B, B) to use as I think this made it even more "expressive" (if you will..) than buttons. One of the few changes I want to make to the SEQ application's functionality for my 808 is to turn the morph feature into something more like this so that the uppercase and lowercase banks are treated as A and B variants which can be switched between, chained together or morphed using a pair of buttons and a pot (a horizontal slider might be the coolest option 8)).

Nice looking board :) I used the tin plating as well for hallucinogen's 808 boards. Good stuff. Allied Electronics sells a simple "tinning liquid" which you drop the boards into for ~ 5 minutes. It's pretty expensive per bottle, but from my expirience one will last you for quite some time.

I can't give specific advice about powering the SID module, but search this area of the forum, and check the wiki. I know using the c64's PSU has been discussed before. Yes, you need to provide power to the core for it to turn on. ;)

What were you trying to upload? Is it possible you were trying to upload an application before uploading MIOS? Which version of MIOS did you upload? Like TK says it does look like you were sending an upload without the PIC requesting it. Have you tried using MIOS Studio with "Wait for upload request" checked off? You have to press start before you power on the core, but doing this has always worked for me. I've never been able to kill a PIC. And I've tried ;D

Ahh yes. 7 bits for MIDI.. I knew that... ::)

Time for some more riddles :) I realize the data format is changing for V3, so this is just out of curiosity. I've been tweedlin' with the sysex in order to create a default pattern for the 808 and I've found some interesting bits reguarding the mute and accent data. I had assumed that only a single bit was needed to represent each step, and that does appear to be the case. Except, there is a whole byte allocated to each 4 steps.. this is odd! Odder still is that the high bits have a different value for each layer, although it does not seem to affect the pattern. Even odder is that each set of low bits is inverted from what you would expect. Follow this: 3E 3E 3E 3E 3F 3F 3F 3F Each location represents 4 steps with the hex "3E" for mutes or "3F" for accents. The pattern is a simple 4-down kick drum, no accents. Decoding the hex to binary we get: 3E = 0011 1110 3F = 0011 1111 Now, assuming each bit represents a step and a 1 represents an on step the pattern plays like this: 1000 1000 1000 1000 Which isn't what we see in the binary, even inverting the bits gets us: 0001 Still not what we want. But at least we can see a relationship here, except that it's inverted on two levels. So from this analysis we see that the sequencer reads each byte from low bit to high bit and the values are inverted. Interesting. Another strange discovery is that changing any value in the mutes or accents causes my SEQ to drop tempo by ~50%. Odd.

This is what I mean, a sort of top-down approach to each application describing how each bit of functionality is accomplished, it makes sense to keep this documentation organized against the files and functions, no? In particular I would have found it invaluable to have a list of the variables used in the MBSEQ application with a breif blurb about what they are, often it is hard to tell from just the name. I know what you mean, but I don't see this as a good reason not to try :). Version numbers can be easily be posted with each page and old revisions can be moved to the back burner or just removed. I also like the idea of making "walkthroughs". ie: once I'm done with the modifications for the 808 sequencer I will post a journal of what I did in code, essentially a case study where I present several objectives and then document the process of completing them.

Geez. I'm beginning to feel like I should stuff a polysynth in the same box with my 808 just to do this sequencer justice.. Awesome work TK!

Ok, Java programmers know what I'm talking about. The online Java API *rocks*. I will often write in Java simply because I know it is so well documented compared to other languages. For those who don't know, check this out: http://java.sun.com/j2se/1.3/docs/api/index.html It's the bomb. So, how about we begin working on a structure for documenting MIOS and all the MB applications in a similar manner? Using the WIKI the results could be very good, and probably reduce the amount of redundant questions reguarding programming MB applications. I've started with some basic ideas on how to format this, check out this page which lists all the files in the midibox SEQ zip file: http://www.midibox.org/dokuwiki/doku.php?id=midibox_seq_v2_4c Scroll down and you can see that there is a link to a page for seq_gp.inc http://www.midibox.org/dokuwiki/doku.php?id=seq_gp which gives an overview of whats in that file along with a list of functions are variables that are used. In time these lists should contain descriptions of what each function does and how each variable is being used in the file. Links to detailed pages on each function where the code can be analyzed line by line should be included too.

Thank you for checking in TK, as usual one of your posts equals several hours of troubleshooting :) I'm planning on basing this sequencer on V3, but I really need to get alot of testing done ASAP so I've been using v2 as a shell. The Stuff I need to test isn't going to change much, although how I handle the interface will. Getting an LCD into a regular size case is really going to be a challenge, I wasn't planning on having such a complete application so I kinda screwed myself in that reguard and I don't think I will reccomend people use one in the "default" configuration as it may complicate the build process (people are already going to have alot to deal with). As you say the features your adding to V3 are very powerful in the context of a drum sequencer :) I'm also planning on making the needed changes to V3 using C instead of assembler since I'm much more familiar with the language. In good news, baby took her first 16 steps today! I had to axe alot of my code and then temporarily remove the humanize features to get everything to fit on the PIC, but she's ticking away now. All the sounds trigger just like they should ;D

Ahhhh.. So I wasn't being very careful when I cleaned out my files this afternoon.. Double checking, yes, indeed some of the mixed up files were from v2.4a.. including the version of main.asm I was assuming to be correct. Thank you TK :) Now, the real problem I have seems to be that my application is too big. the .hex is 54kb, which I figured would be allright, but while uploading it went well beyond 7c0000 . There are two sections of the program that I would look ar first, the one I really think is bad is the following code I used to init a bunch of variables, surely there is a better way than this: movlw 0x24 movf BD_NOTE movlw 0x25 movf SD_NOTE movlw 0x26 movf LT_NOTE movlw 0x27 movf MT_NOTE movlw 0x28 movf HT_NOTE movlw 0x29 movf CP_NOTE movlw 0x2a movf MA_NOTE movlw 0x2b movf RS_NOTE movlw 0x2c movf CB_NOTE movlw 0x2d movf CY_NOTE movlw 0x2e movf CH_NOTE movlw 0x2f movf OH_NOTE movlw 0x00 movf BD_PIN movlw 0x01 movf SD_PIN movlw 0x02 movf LT_PIN movlw 0x03 movf MT_PIN movlw 0x04 movf HT_PIN movlw 0x05 movf CP_PIN movlw 0x06 movf MA_PIN movlw 0x1a movf RS_PIN movlw 0x1b movf CB_PIN movlw 0x1c movf CY_PIN movlw 0x1e movf CH_PIN movlw 0x1f movf OH_PIN I inserted that into the begining of USER_Init just to keep things simple... but it's rather ugly... .... so I'm a java programmer with 2 gigs of RAM on my PC.. what of it ;) it's just about time for bed now.. I'll get back to work on this tommorow. EDIT: I just checked the filesize, it's 55,026 bytes. I didn't find mention of the available application space, but I'm sure it's out there. Tommorow.

Allright, I think I've found something. This problem may have been there all along without me noticing it. I googled the error number and found this: http://www.siliconchip.com.au/cms/A_102355/article.html Snippet: That didn't solve the problem, but at least it's something. There is also this site which shows that the 118 error message can be related to the ORG instruction http://www.piclist.com/techref/microchip/gotchas.htm Looking further I found this, which begins to confirm my suspicion that the error really isn't important http://list.picbasic.com/forum/messages/6851/6994.html?1077317427 And then, finally this snippet from the same sources: Unfortunatly I havn't found a way to force the linker to create a .hex file, so I can't really test this.

I was finishing up on some changes today and, somehow, I got this message while make-ing the file. Error[118] C:\ARCHIVE\MIOS\X0XSEQ\MAIN.ASM 666 : Overwriting previous address contents (7BFE) Error[118] C:\ARCHIVE\MIOS\X0XSEQ\MAIN.ASM 666 : Overwriting previous address contents (7BFF) From these lines in main.asm: ;; ---[ ensure that BSL location won't be overwritten ]--- org 0x7bfe dw 0x0000 It's the "dw 0x0000" thats causing the error. At one point today I had a bunch of files that were in the wrong workspace (I'm using MPLAB) that I cleaned up. I don't know if this could be related, I doubt it is. Since I don't really know where to start troubleshooting this I've been working on the following warnings instead: Warning[203] C:\ARCHIVE\MIOS\X0XSEQ\MIDI_EVNT.INC 81 : Found opcode in column 1. (call) Warning[202] C:\ARCHIVE\MIOS\X0XSEQ\MIDI_EVNT.INC 84 : Argument out of range. Least significant bits used. From these lines that I've added to midi_evnt.inc: call MIOS_DOUT_PinSet1 ; Single level of accent shared by all instruments CheckCH movf MIDI_EVNT1, 0 ; Move note value to W to use ANDL* xorlw CH_NOTE ; value for CH (Note#20) EDIT: I got it, as I suspected they were stupid mistakes on my part. The "Found opcode in column 1" message meant exactly what it said. The CALL instruction needs to be in the second column. The "Argument out of range" message was caused by the fact that I was using xorlw with a file register as an argument. I should use xorwf instead. Properly formed this is what the code should look like: CheckCH movf MIDI_EVNT1, 0 ; Move note value to W to use ANDL* xorwf CH_NOTE, 0, 0 ; value for CH (Note#20) bnz CheckRS movf CH_PIN, 0, 0 ; if the result was 0 play CH call MIOS_DOUT_PinSet1 ; play CH, pin cleared elsewhere goto MIDI_EVNT_Send_Ax

Awesome! thanks TK ;D I figured that the mute information could not be decoded by reading the hex and was just about to start converting those tables into binary and decimal :) I've got too much else to get done, but in the end I'll complete that wiki page by combining those documents and labeling the string with positions for drum mode and regular mode. And, I assume that the offsets is a new addition to that documentation? Otherwise I need to find the most recent SEQ .zip (2.4c, right?)

Good point :) Now, chances are pretty good I'll have to take a nap once I get home from work today and therefore I won't get much done (still Fn sick..). But here is what I'm thinking now: There are definatly some recognizable patterns in the dump data, look at colums 9-12 in the first three sets. Those alone are enough to re-inforce my assumption that the data is at least partially comprised of 16 byte rows. However, I've not yet figured out where certian data is represented. Since this is an unkown I'll be starting by figuring out what information the 320 bytes must represent. We know that a pattern contains information about 4 tracks, each with 3 layers and each layer with 16 positions that hold a value. We know that the largest value a position needs to hold will be 127, which requires 7 bits. We also know that a position being muted only needs a single bit. We know that other track information needs to be represented as well. The BPM divider, the play mode and direction, the event type all need to be represented as well. We can assume that TK has been, as always, efficient with his code and little to no space will be wasted. Next, what kind of specific information can we gather about this particular string? We know that each layer will have it's own mute value and it will initialzed to off (0?) We know that the information is used differently in drum mode and is probably more compact. Perhaps someone has a .syx of a blank pattern they could send me? I still can't upload to a PIC.. SO, with these assumptions what can we see? Perhaps it's just a coincidence but the first 12 rows of data look likely to hold the information about the 12 tracks. We can see that there are 3 sets of similar rows, leading to the conclusion that each set of 4 rows represents layers A, B and C for each of the 4 tracks. We can see that within each "Layer" there are only a few differences between rows. The first and most interesting difference is the 9th column. This is the only unique column amoung the 12 rows and it is interesting to note that all the values between 24 and 2F are represented here. The only other inconsistancy are the first 4 columns of the first row which contain "3E" instead of "3F". Only this first "layer" has this feature. We can see that each row of each layer starts with 8 identical values. This is good, perhaps what we are looking for. These 8 values are followed by rows 9-12 with their interesting relationship discussed. It is interesting to note that column 12 has the same value for every row. The last 4 colums for each "layer" are all the same value. It is also interesting to note that there is an extra byte in the footer. Although the "10" isn't part of the proper sysex command I don't believe it could be part of the data dump as we already have exactyly 320 bytes..