moogah

The background was bright red and the letters are pink. Like I said, nothing *at all* like the picture.

Be careful with the pictures from crystalfontz. I ordered the same LCD you are asking about and it doesn't look anything like the picture. I called their tech support to ask about this and the guy said thats just the way it is... I've been more wary of looking for nice colored LCD's from them now.

Then certianly you know that scientists use expirimentation to go from what they know, to what they don't know! Stick with it, the real fun begins when you get some hardware on the bench and start measuring what happens! Knowing everything up front just guarantee's that you won't discover anything new along the way ;)

Yo, keep it mellow dood, if TK can't teach you noone else around here is likely to step up. All the information you need is right at your fingertips, right here in this forum! Have a little patience, learn to expiriment and develop your own answers, this way adding to our knowledge base! You are close in your understanding of what the deadband does and how the functions affect it, but since I myself am not completely clear on what you are having the most trouble with I can only explain it like this. When MIOS sends a signal to a motor fader there is no way for it to determine an *exact* position where the fader will stop because the electronics that control the motor are only so precise, and therefore there is a certian "resolution" to the movements MIOS can make. Follow this example: -Fader A is currently set to 0, at the bottom of it's range. -MIOS determines that the fader need to be at 75%, so it begins sending the motor a series of pulses which move the fader and at the end of each pulse MIOS reads the value of the fader to see if it has arrived at 75% yet. The problem is that the amount of movement per pulse sent to the motor cannot be precisly controlled, so that a situation like this is likely to occur: at the end of a pulse the fader value reads to be 74%, so another pulse is sent, however, this puts the fader at 77%, so MIOS again sends another pulse (in the reverse direction), however, this brings the fader down to 73%.. and MIOS sends another pulse.. now we end up at 76%. This can and will go on indefinatly, so in order to stop this oscillation the deadband parameter sets a certian range for which MIOS will consider the position to be good enough. SO, lets go through the above example again, but this time with a deadband setting of 6%. At the end of a pulse the fader value reads to be 74%. We are looking to get 75%, but with a deadband parameter of 6% any value between 72% and 78% will be considered good enough by MIOS, so this time no more pulses are sent, even though we have not actually made it to 75%. The deadband does not set the "increment value" so that the fader would move 6% at a time, the fader still moves smoothly. Now, to my understanding the deadband is not set in percentage values so you cannot use the numbers I have used literally. You will have to do some expirimenting and *reading* on your own to get this all figured out.

I should qualify my comment a bit better: A posting of the source, with hyperlinks! Tell me that wouldn't be useful ;D And, yes I realize that is going to be alot of work, and I still have alot of source code to peruse before I can tackle such a thing.

... The documentation is pretty good, actually.. Were you expecting something like the Java API Reference? That said there definatly has to be a section added to the WIKI about the MIOS functions so that people can add their practical expirience in as they go along, thus achieving a more robust description of the MIOS functions. One thing I would like to see is a posting of the source for each function, but in reality I'm not going to have time to make a serious attempt at this until August at best (nor will I really understand MIOS until then anyway). ... I've still gotta post a writeup on various distortion circuts.. once I build them..

Wow! Those buttons all look incredible! Even more so now that I've tried to make some of my own, and they don't look anywhere near as good as those. I turned mine on a lathe and made a hole in the bottom that fits over the switch like pay_c's.. However.. the light up factor is nowhere near as good as that looks! Would you say that those pictures are an accurate representaion of what it looks like IRL? I'm having trouble with getting the whole button to light up, and it seems like it is the shaft of the switch that is blocking the light from spreading out.. something that does not appear to be a problem in the picture above. The only way I can get close to those results is to put the LED directly under the button and even then I don't get a nice smooth dispersion of light like what appears in the picture I'll post some pics tonight..

I'm pretty sure you end up with the same thing that way, once you work it out. Same goes for modularity, you have to check for all 12 note values, reguardless and you have to branch out when you find a match. The simplest way is to map all the instruments to sequential note numbers, this way they can be checked in a simple loop. This loses the ability to make your own mapping, so I don't consider it ideal.

Ok, new post time. This is what I've got done today MIDI_EVNT_Send_9x ; Note On movlw 0x5a ; If velocity is > 90 cpfsgt MIDI_EVNT_VALUE MIOS_DOUT_PinSet1(ACCENT_PIN) ; Single level of accent shared by all instruments CheckCH movf MIDI_ENVT1, 0 ; Move note value to W to use ANDL* xorlw CH_NOTE ; value for CH (Note#20) bnz CheckRS ; if the result was 0 play CH PlayCH MIOS_DOUT_PinSet1(CH_PIN) ; play CH, pin cleared elsewhere goto MIDI_EVNT_SendAx CheckRS movf MIDI_ENVT1, 0 ; xorlw RS_NOTE bnz CheckBD PlayRS MIOS_DOUT_PinSet1(RS_PIN) goto MIDI_EVNT_SendAx CheckBD movf MIDI_ENVT1, 0 xorlw BD_NOTE bnz CheckSD PlayBD MIOS_DOUT_PinSet1(BD_PIN) goto MIDI_EVNT_SendAx CheckSD movf MIDI_ENVT1, 0 xorlw SD_NOTE bnz CheckCP PlaySD MIOS_DOUT_PinSet1(SD_PIN) goto MIDI_EVNT_SendAx CheckCP movf MIDI_ENVT1, 0 xorlw CP_NOTE bnz CheckOH PlayCP MIOS_DOUT_PinSet1(CP_PIN) goto MIDI_EVNT_SendAx CheckOH movf MIDI_ENVT1, 0 xorlw OH_NOTE bnz CheckMA PlayOH MIOS_DOUT_PinSet1(OH_PIN) goto MIDI_EVNT_SendAx CheckMA movf MIDI_ENVT1, 0 xorlw MA_NOTE bnz CheckCB PlayMA MIOS_DOUT_PinSet1(MA_PIN) goto MIDI_EVNT_SendAx CheckCB movf MIDI_ENVT1, 0 xorlw CB_NOTE bnz CheckLT PlayCB MIOS_DOUT_PinSet1(CB_PIN) goto MIDI_EVNT_SendAx CheckLT movf MIDI_ENVT1, 0 xorlw LT_NOTE bnz CheckMT PlayLT MIOS_DOUT_PinSet1(LT_PIN) goto MIDI_EVNT_SendAx CheckMT movf MIDI_ENVT1, 0 xorlw MT_NOTE bnz CheckHT PlayMT MIOS_DOUT_PinSet1(MT_PIN) goto MIDI_EVNT_SendAx CheckHT movf MIDI_ENVT1, 0 xorlw HT_NOTE bnz CheckCY PlayHT MIOS_DOUT_PinSet1(HT_PIN) goto MIDI_EVNT_SendAx CheckCY movf MIDI_ENVT1, 0 xorlw CY_NOTE bnz MIDI_EVNT_Send_Ax PlayCY MIOS_DOUT_PinSet1(CY_PIN) and USER_SR_Service_Finish ;; ---[ handle with control surface variables (flashing cursor, etc) ]--- clrf MIOS_PARAMETER1 movlw 0x04 call MIOS_DOUT_SRSet movlw 0x05 call MIOS_DOUT_SRSet goto CS_MENU_TIMER Now, aside from being a bit long to look over I think this will run with a minimal impact on the SEQ. It would be nice if I didn't have to movwf MIDI_ENVT1 each time. Even so the worst case as I understand it is when a every instrument is triggered at the same time, meaning that around 300 instructions cycles will pass before everything has been triggered(EDIT: this doesn't take into account the number of instructions in each MIOS_DOUT_PinSet call). This is still only about 1/3 of a millisecond ontop of whatever latencies are already part of the SEQ. Now, what I need to do is define constants for each DOUT pin and for each note value, that part is fairly easy but a "memory map" for MIOS and the SEQ would be really nice so as to easily find registers that have not been used. The only question I have at this point is how best to assign a default value to these constants, putting them in USER_Init or somewhere nearby makes sense to me. There is one thing that has been bugging me about app_defines.h ;; track record structure SEQ_TRKSTATEx EQU 0x00 ; flags: see seq_core.inc (SEQ_TRKSTATE_*) SEQ_TRKMUTED0x EQU 0x01 ; muted steps 1-8 SEQ_TRKMUTED1x EQU 0x02 ; muted steps 9-16 SEQ_TRKPLYTICKx EQU 0x03 ; number of MIDI clock ticks until next step will be played SEQ_TRKSTEPx EQU 0x04 ; the track step SEQ_TRKPOSx EQU 0x05 ; the track position SEQ_TRKQUEUELx EQU 0x06 ; length counter ("note off" once it is zero) SEQ_D_TRKMUTED_0x EQU 0x00 ; muted steps 1- 4 SEQ_D_TRKMUTED_1x EQU 0x01 ; muted steps 5- 8 SEQ_D_TRKMUTED_2x EQU 0x02 ; muted steps 9-12 SEQ_D_TRKMUTED_3x EQU 0x03 ; muted steps 13-16 SEQ_D_TRKACC_0x EQU 0x04 ; accented steps 1- 4 SEQ_D_TRKACC_1x EQU 0x05 ; accented steps 5- 8 SEQ_D_TRKACC_2x EQU 0x06 ; accented steps 9-12 SEQ_D_TRKACC_3x EQU 0x07 ; accented steps 13-16 this shows different constants being assigned to the same register.. right? EDIT: I found the little note at the bottom of app_defines.h about what address space is left open. ;; free for your pleasure: 0x360-0x37f ;; and 0x380-0x3ff if the AIN handler is disabled BD_PIN EQU 0x360 SD_PIN EQU 0x361 LT_PIN EQU 0x362 MT_PIN EQU 0x363 HT_PIN EQU 0x364 OH_PIN EQU 0x365 CH_PIN EQU 0x366 CY_PIN EQU 0x367 CP_PIN EQU 0x368 CB_PIN EQU 0x369 RS_PIN EQU 0x36a MA_PIN EQU 0x36b ACCENT_PIN EQU 0x36c BD_NOTE EQU 0x36d SD_NOTE EQU 0x36e LT_NOTE EQU 0x36f MT_NOTE EQU 0x370 HT_NOTE EQU 0x371 OH_NOTE EQU 0x372 CH_NOTE EQU 0x373 CY_NOTE EQU 0x374 CP_NOTE EQU 0x375 CB_NOTE EQU 0x376 RS_NOTE EQU 0x377 MA_NOTE EQU 0x378 BD_ACCENT EQU 0x379 SD_ACCENT EQU 0x37a LT_ACCENT EQU 0x37b MT_ACCENT EQU 0x37c HT_ACCENT EQU 0x37d OH_ACCENT EQU 0x37e CH_ACCENT EQU 0x37f CY_ACCENT EQU 0x380 CP_ACCENT EQU 0x381 CB_ACCENT EQU 0x382 RS_ACCENT EQU 0x383 MA_ACCENT EQU 0x384

Which element? The one with the wires wrapped arond it is an inductor.

Thanks guys. XOR and BZ are what I'm looking for I think. The datasheet is a bit vague here but I think I can specify a relative branch location, right? something like PC+2? got a question right off the bat, how do I identify a binary number? 00010100b? EDIT: how about this: movf MIDI_ENVT1, 0 ; Move note value to W to use ANDL* xorlw 00010100 ; value for BD (Note#20) bz PlayBD ; if the result was 0 play BD PlayBD MIOS_DOUT_PinSet1(BD_PIN) ; play BD, pin cleared elsewhere movf MIDI_ENVT1, 0 ; Move note value to W to use ANDL* xorlw 00010101 ; value for BD (Note#20) bz PlaySD ; if the result was 0 play SD PlaySD MIOS_DOUT_PinSet1(SD_PIN) ; play BD, pin cleared elsewhere This brings me to another problem.. I had originally tried to use the debugger to get an idea of how the SEQ works, however, it doesn't get any further than the init loop as there is no external stimulus. Has anyone tried to setup a scenario for the SEQ? I assume this is not practical, so how have you gone about testing code fragments like this? Also, is there anything like a break statement to skip over the remaining checks? EDIT: Like this mabey: CheckBD movf MIDI_ENVT1, 0 ; Move note value to W to use XORLW xorlw 00010100 ; value for BD (Note#20) bnz CheckSD ; if the result was 0 play BD nop PlayBD MIOS_DOUT_PinSet1(BD_PIN) ; play BD, pin cleared elsewhere goto MIDI_EVNT_SendAx CheckSD movf MIDI_ENVT1, 0 ; Move note value to W to use ANDL* xorlw 00010101 ; value for BD (Note#20) bnz CheckCH ; if the result was 0 play BD nop PlaySD MIOS_DOUT_PinSet1(SD_PIN) ; play BD, pin cleared elsewhere goto MIDI_EVNT_SendAx The NOP's are there because, assuming I'm reading the datasheet right, the BNZ command will skip the next line if the Z bit is set (meaning the compare was a match) EDIT: (been a busy day!) I've got a few questions about this USER_SR_Service_Finish function. Some of the trouble I'm having is due to the fact I can barely understand German, much less tech-speak in German so I'm probably asking stuff that is in Hallucinogen's thread. It seems that the function has been updated since then as I don't see the call to CS_MENU_TIMER in the snippets from you or Hallucinogen there. Now, what is causing me trouble is understanding how the Registers work to address the DOUT. Does each register address one of the 595's? I see that the MIOS_DOUT_SRSet function sets the SR specified in WREG to the value of MIOS_PARAMETER1. However, if this is the case the code provided would be clearing nearly every LED on the device, certianly not what we were looking for. If I understand what is going on I will be addressing SR's 0x04 and 0x05 which clears the first two registers on the second DOUT board USER_SR_Service_Finish clrf MIOS_PARAMETER1 movlw 0x00 call MIOS_DOUT_SRSet movlw 0x01 call MIOS_DOUT_SRSet movlw 0x02 call MIOS_DOUT_SRSet return USER_SR_Service_Finish ;; ---[ handle with control surface variables (flashing cursor, etc) ]--- goto CS_MENU_TIMER

I got some time to work on this today. Checking the velocity value was easy, but checking the note numbers was a bit more difficult. Here is what I've got (with a single accent and only the BD and SD): movlw 0x5a ; If velocity is > 90 cpfsgt MIDI_EVNT_VALUE MIOS_DOUT_PinSet1(ACCENT_PIN) ; Single level of accent shared by all instruments movf MIDI_ENVT1, 0 ; Move note value to W to use ANDL* andlw 11101011 ; "Binary complement" value for BD (Note#20), ; result is 0 when values match (?) movwf SOME_REG ; move W into a register to use DCFSNZ dcfsnz SOME_REG, 1 MIOS_DOUT_PinSet1(BD_PIN) ; play BD, pin cleared elsewhere andlw 11101010 ;" Binary Complement" for SD (#21) movwf SOME_REG dcfsnz SOME_REG, 1 MIOS_DOUT_PinSet1(SD_PIN) ; play SD, pin cleared elsewhere return The process of moving the note value into W to use the AND on it and then moving back into an F to check if it is zero seems suspicious to me. Although even doing all this for all 12 instruments adds less than a 10th of a millisec, by my calculations anyway. Is there a way to check if W is zero? Or perform an AND on a f?. I also have the feeling that "Binary Complement" is the wrong term too.

!! Thats some good stuff right there! Thanks TK!

Fatar is pretty much the only manufacturer of keybeds in the world. A few companies used to make their own (Yamaha was one, I believe) but even most of them now use fatar boards. To my knowledge Fatar in only interested in OEM sales so you can't buy just a few keybeds at a time from them.

Indeed I got the idea from him! I was hoping to draw him into the forum again, but I would like work through the problem myself as a learning excersise.

Dood.. if you find one be sure and let the world know! There is virtually no source for keybeds anymore, but don't let that discourage you. Your best bet is a broken old synth that still has good keys.

Thanks stryd, got quite a few AHA!'s in there. It's going to be some time before I get used to the fact that functions dont return unless you specify it! Same with how variables are handled, arguments aren't really passed etc.. Good stuff tho, even with the C wrapper available I feel like I get a much better idea of what I'm working with in assembly.

Ahh! I lost track of this post! In any case I'll echo the fact that I'm just passing on what I've heard elsewhere, but with the added caveat that the people from whom it came are trustworthy. Sure the full allegations of chipforbrains are a bit tough to swallow, but, knowing a bit about how shit works over in Hong Kong it really isn't too hard to believe. One thing is certian, many people who have ordered from HKSS have received product that is of substantialy lower quality than the auctions seem to indicate, or something totally differnt (those MN3005's are not too likely to be the real deal, I'll post about it when and if mine arrive). In fact I have not received the order I placed over a month ago now.

So, after nearly a year of studying and soldering I've finally got a project that is worth writing some of my own code for (hallucinogen's 808 clone). I plan on using a modifided MBSeq to trigger the 808 through DOUT pins, saving me the need to build an AOUT which doesn't have enough pins for all the sounds anyway. Accent will be achieved by sending some voltage level (derived with a simple voltage divider) to all the instruments and using a switch that is also triggered by a DOUT pin (this DOUT module is handy!). So, in order for this design to work each instrument needs 3 things: a short 5v pulse to trigger it, a switch to turn the accent on/off via another 5v signal and a voltage level for the accent. Now, as it is the SEQ has just about everything I need, so I really do need to do much work. All I really need to do is set DOUT pins along with the midi events that are being triggered. This has two advantages: it's simple and it allows the sequecer to behave just like a normal MBSeq to external equipment (so I can write basslines right along with the drums ;D). Now, after tracing through the source code a bit I've identified midi_event.inc as the file where most of my changes will need to be. When a midi note is triggered in a drum track I need to first read it's value to determine which instrument it is and then set the appropriate DOUT pin(s). Here is the code fragment that most interests me: MIDI_EVNT_Send call MIOS_MIDI_BeginStream ;; branch depending on MIDI status SET_BSR MIDI_EVNT0 swapf MIDI_EVNT0, W, BANKED andlw 0x07 JUMPTABLE_2BYTES_UNSECURE ; 8 entries rgoto MIDI_EVNT_Send_8x ; Note Off rgoto MIDI_EVNT_Send_9x ; Note On rgoto MIDI_EVNT_Send_Ax ; Aftertouch rgoto MIDI_EVNT_Send_Bx ; Controller rgoto MIDI_EVNT_Send_Cx ; Program Change rgoto MIDI_EVNT_Send_Dx ; Channel Pressure rgoto MIDI_EVNT_Send_Ex ; Pitch Bend rgoto MIDI_EVNT_Send_Fx ; AOUT ;; sending three bytes: MIDI_EVNT_Send_8x ; Note Off MIDI_EVNT_Send_9x ; Note On Now, aside from the fact that I don't yet understand how the JUMPTABLE implements a switch statement there is something quite suspicious about this code.. see it yet? The functions for sending note on and off messages are empty! Surely this cannot be correct so I must not be looking in the right place, no? Moving on from there for a miniute there is one more dilemma, to trigger the sounds I only need a very short gate signal, meaning that the note off event should be sent almost immediatly after the note on. Possibly this is easy to do by simply setting the gate length for the drum tracks to a very small value, but I suspect that even the smallest gate length is still a good bit longer than 1ms. Furthermore this would make it difficult to layer drum sounds from external equipment, so idealy there will be special handling of notes sent to DOUT pins in order to keep the gate length very short. Possibly I could simply add some simple differetiators in hardware to accomplish this as well, but additonal hardware just seems uneccessary at this point

Thanks stryd, thats what I needed. Those chips look pretty sweet, but I can't think of something real practical for it yet. At least not with a single one.

Yes, but this is the problem! I've been searching for these parts for a couple days now and clearly I don't remember enough to find where the threads were.

Not too long ago I had found a couple threads here, one was about some nifty multicolored LED arrays, the other was about a nifty configurable analog processor on a chip. I can't seem to find them anymore..

Under no circumstances should you buy *anything* from ebay member HongKongSuperSeller AKA Musical Reduction Shop. Although some people have had decent transactions with him it has recently come to light that the majority of the IC's he sells ended up in China because they were trash to be recycled, or wose they are re-labled IC's (meaning some little chinese kid has a job sanding the labels off old IC's over there). Rumors abound about the real nature of his buisness, but one thing is for sure, the deals are too good to be true so just pass them by.

Cool, your obviously knee-deep in this already, while I've just gotten my feet wet. One more idea from my notebook: "Booth" and "Program" patterns, rather like how a DJ has two different mix busses on his mixer so he can cue of the next track without the audience hearing it. Now, obviously to make this really work the sequencer would need to be hooked up to a mixer so it's not a practical thing to do, but what sticks in my mind is the ability to begin editing a sequence before you start playing it back to the audience. Good stuff for live improv! As for what the edit buttons could be while in "playback" mode the first thing that comes to mind is part mutes. This way you can spend time at a show layering parts into songs and easily switch into edit mode to make changes on a part that is playing (or about to play) Hmm, good point. I definiatly like sequencers that don't require a save button like this. Copy&Edit really makes the most sense. Could you also insert a "mute part b" event into the first step of part a? In this case it would be an event that should happen before the first step of part a. Triggering different sequences depending on the context of how they are being played brings up the idea of having sequence variations (a bit like the 808). As for triggering a fill when a certian pattern gets cued, it's easy in a regular sequencer, all you need is globals for "prevPattern", "currentPattern" and "nextPattern" and have the sequencer check these values. Good point about not being able to tell what a given argument is going to be.. that is going to take some pondering. I'm down with sticking to a framework and keeping up the tradition of extendability that TK started.

Sure, keeping in mind I don't have a working SEQ in front of me, so perhaps this will sound odd. Instead of storing an entire pattern with it's 4 parts as a single chunk of data like the SEQ, store the parts seperatly and create patterns which are simply a collection of parts that can be played together. This way, when you start jamming you can simply import the drums from another pattern and get going right away. This way you have a 'library' of parts and each pattern is just a group of parts, connected by your sequencer timing magic. Your design accomodates this quite well I think since all you would need is the handle to a part stored in the pattern data to call a playPart() type function. Now, so that a special "part edit" mode is not needed some logic would be neccessary, see if this makes sense: Pattern 1 contains: Part A Part B Pattern 2 contains: Part B Part C If I begin to edit Pattern 1 and make changes to Part B the sequencer automatically copies that information into a new part and changes the handle in Pattern 1 from part B to Part D so that Pattern 2 is not effected. If I am editing Pattern 2 and decide I want another part the sequencer simply creates a new part adds it to the list of parts included in Pattern 2. You can kinda think of each Pattern like a 'window' looking into the big list of parts and allowing the user to select only those they are interested in for playback or editing. Also, I should elaborate on the "triggers". I had originally been thinking of this as a software sequencer, so perhaps it's really just too complicated to implement in hardware.. Consider being able to set a "Rule" for a pattern so that if part A starts playing, Part B gets muted or if Patten 1 gets cue'd then play a fill (think about that one!). What would be needed is a way for the user to specify events and choose a function to call on the occurance of that event. It is fairly simple to setup a trigger that will respond to the midinote #120 being played, but more complicated to specify that if one event is happening and another starts then do something. It may also be too difficult to get a PIC to do all the checking neccessary to recognize certian events, I believe it would be neccessary for the uC to 'look ahead' for events only when there is a change of state in the sequencer like a part being unmuted, a new pattern getting cue'd or some incoming MIDI. I've got some logic written out here, and I'm sure it can be done, it's a matter of what kind of interface would be needed to make it useable. I also think it's quite important to never have to stop the sequencer. I don't recall exaclty how the SEQ works (I had to take mine apart for other prototypes) but the user should be able to switch from pattern play to pattern write with the press of a button. Essentially pattern play mode is simply a lock on the edit buffers, which frees up the edit buttons for playback specific functions. Oh yea, reguardless of the EUSART getting working with the new PIC I'm giving a BIG thumbs up to the idea of incorporating midi synced LFO's and other such goodness. The sequencing you describe BEGS to be connected to modular equipment through an AOUT By chance your interested in splitting this project up? I won't have alot of time to work on it until this summer, but I'm really interested in seeing a next gen sequencer become available!