Jump to content

davotron

Programmer
  • Posts

    30
  • Joined

  • Last visited

    Never

About davotron

  • Birthday 01/01/1

Profile Information

  • Gender
    Not Telling

davotron's Achievements

MIDIbox Newbie

MIDIbox Newbie (1/4)

0

Reputation

  1. My first MBSID has 8 buttons and an encoder with a push button under the shaft - function buttons 1 - 5, page up/page down, shift and then the encoder is used for menu up/down and to enter paramater values, the button in the encoder is the "enter" button so to speak.
  2. It may be worth looking at the Core32 and using the OSC protocol over ethernet... or even ASID this way. Core32 has a USB port also. I'm sure midi would work though, it just feels a bit clunky to have all those CC params, less slick as it were than a more direct and faster software control.
  3. That case looks awesome joewhat, keep us posted! but what communication protocol are you going to use between the PC and the MBSID? this is the question!
  4. Ah yes, ASID.. cheers, will have a look at this. I love the idea of having a tracker that has exclusive MBSID parameters though as the thing is so damn powerful compared to existing SID based synthersisers. Of course you could just use something like Renoise and just set up three tracks for the three SID oscillators and assign CC parameters to all the MBSID params..
  5. Hi Guys, This kinda goes back to my previous direct SID control question (I realised since it is quite possible to hook up a SID to a parallel port or serial interface and control it that way, if one was so inclined!). How cool would it be to have a MBSID parameter specific tracker (with three columns, one for each oscillator) that could talk to a core32 and SID directly over OSC or a direct USB protocol... failing this has anyone had any joy with a program like Renoise in playing SID music with a whole load of midi events? I find renoise is complicated.. cool but complicated. It almost defeats what made a tracker so good: that one could sequence SID music and play it "directly" on the machine (much like other trackers on the Atari ST and Amiga 500).
  6. It's just a buffering principle, you could use the very simple bipolar transistor (essentially a "current buffer" in my opinion) or a simple op amp buffer (voltage follower), or voltage amplifier. Opto couplers would work, but there are a few more bits involved, i.e. the opto couple would be used to drive another transistor stage I would imagine (think of an old opto compressor). A pair of 74HC04 inverters one into the other makes a nice simple non inverting JFET buffer, as long as the single doesn't get clipped and it's biased properly. Just take the audio out of the SID into the simple transistor circuit for the easy option... you could in theory take several buffered feeds from the SID output before it's actually loaded down too much.
  7. Ah yeah, of course! I have been looking indeed. Just trying to generalise the point of why bother talking to the SID directly when MIOS and the SID firmware do it so easily and so well, and give you tons of awesome functionality. This made me thought of something else: is the sine wave generated from a table of values for a full period, i.e. sin(2?)? Could someone, in due course, if they were so inclined, edit the software and add the functionality of storing other wavetables somewhere and use these? Like the sounds of the early WT synths? But Reaktor? 24 voices! awesome! sounds great!
  8. I was thinking back more to the days of the C64 command line and POKE to address a certain reg and then give it some value to make sounds, kinda bypassing any "hardware" i/o, Although I did think this editor is most useful. But why I hear you say? I though it would be cool to be able to enter a command on the MIOS studio debug terminal, similar to "POKE" to access the SID registers directly, so a small tracker program could be built to do the same etc to make cool sequenced tracks up. Although there's actually no need for this as you could just send all the stuff as normal midi control data and have the same effect (as obviously MIOS and the SID app do it already).
  9. Not sure if this has been discussed on here previously: on the much useful debug terminal front, I've realised this could open up direct manipulation of the SID registers quite easily which opens up a whole bunch of possibilities. How cool would it be to have a SID specific audio tracker program running on your PC etc.
  10. Thanks for that, if I can help out I shall! I've done the odd bit of assembler, C/C++ and BASIC over the years, quite like the usage of the linux style terminal shell and associated commands. I haven't had a chance to look at the new MIOS studio beta; what level of i/o has already been implemented in the debugging terminal? How cool would it be to have small debugging commands to show MIDI i/o activity (like a midi ox terminal), button presses etc all in real time! (although I guess this is very possible with the current OS with the LCD display) I was thinking more a small file system set of commands, so you could edit front panel buttons, patches, midi/ethernet set up etc directly from a terminal. How is MIOS32 structured (trying not to sound too daft here!): do you have a form of "file system" hierarchy with a "root" then within there directories where progs/apps/commands are executed from and files are stored? I suppose with MIOS8 it is very low level and more embedded so to speak, in the sense that you compile a program with your major hardware configuration set up, and it essentially just runs therein, all in one enclosed program with limited debugging i/o (unless a specific app was written to test i/o of course!)
  11. I think I need to walk before I can run! I'm definitely interested though, certainly an eye opener knowing this exists now. I'll have a bit more of a play when I've got my first midibox SID finished - it works, just need to sort out a nice enclosure for it etc. I like the idea of terminal control via midi though, I guess it is essentially just RS232. Thinking of going for a stereo version next, but it will most certainly have an STM32 core. Had considered using an atmega 32 ARM a couple of years ago to control a SID chip, but the STM32 definitely has a few more plus points.
  12. cool, that's awesome, I must have a play with one of these things!
  13. I was just had a thought having worked on various embedded systems where I used to work: how nice would it be to have a serial port on the STM32 core that you could hook up to a PC comms terminal (or via ethernet to a telnet connection?!) that could be used to access a "higher level" version of MIOS. Instead of editing config files, then compiling/assembling etc, config files could be edited from a terminal within the file structure of the OS whilst "online" so to speak - could be really useful for frontpanel debugging, editing patch files/ensembles etc I was playing with a very simple low level command line version of embedded linux once, thought how cool would that be.. I don't know anything about FreeRTOS, is there any implementation of this in the pipeline? Sorry if its been talked about before or implemented etc! It's a shame there is no version of an embedded RiscOS... David
  14. Aha, thank you, I wondered about some way of banking the patches into 2 lots of 64, I shall get on the case. Thanks, David
  15. Howdy.. I had a couple of spare 24LC256 EEPROMS lying around, so thought I'd try to use them as banksticks for my MB SID, running midibox_sid_v2_0_rc28 to give me 64k instead buying some 512's. I assumed if I hooked them up in parallel to the core, but made one "hardware address" A0 and the other A1 I would get 2 x 32k giving me a full 128 slots available to store patches (ensembles aside for now). This doesn't seem to work though, they are both formatted correctly though. I get the first 64 patches uploaded, then 65 - 128 say "no bankstick"; if I swap the addresses around, make the one that was A0 A1 and A1 A0 I get the first 64 saying "empty" (which is correct as nothing was uploaded to this other chip) and the next 64 saying "no bankstick". This proves the connections of the memories to the core must be right - I just have a little address jumper to either ground or tie address pin 1 (physical pin 1) of the memory to +5v, so the memory at A0 is seen but the other isn't. Am I missing something? It's probably easier to just get some 512k memories ordered! but thats no fun, so I thought I'd run it past you guys to see if I've missed something fundamental!
×
×
  • Create New...