yogi
-
Posts
218 -
Joined
-
Last visited
-
Days Won
5
Content Type
Profiles
Forums
Blogs
Gallery
Posts posted by yogi
-
-
The Teensy idea sounds very interesting. It could be something much more than a UART extension, more of a smart peripheral.
Thinking again of the GM5 design, couldn't a dsPIC or PIC32 (DIP packages if need be) implement multi soft uarts also? IIC could still be used for the core interface but with a slight extension to MIOS32 for an interrupt or a polled input. Or maybe the CAN bus?
Yogi
-
Not to dissuade you, as more options are always good. Especially if you added full duplex into the mix. But just my minor user's viewpoint: the 'f88 design is attractive because of it' scalability and the fact that hacking the firmware can be done somewhat easily, for custom apps like the Speakjet. At some point would like to have a 57,600 com port for another project.
Currently using a single IIC midi Tx to support a Waveblaster GM board. I could have used one of the UART's on the core32, but I tend to view them as 'precious' and the IIC bus is underused.
Regardless if a new design is developed, the 'F88 based one will still be viable. But if the goal is more of a GM5 like solution (maybe on the SPI bus), that too would be a great addition for complex midi routing.
Interested, Yogi
-
Not to speak for serge, but Serda Co's Dream Blaster boards are modern recreations of the GM daughter boards that plugged into the Soundblaster cards (FM) that had a 'Waveblaster' header. The videos show the S1, and the X2 is a more advanced model. Back in the day Roland, Yamaha and others sold GM cards to upgrade from the FM. The cards accept TTL Midi and support full General Midi wavetables. It was noticed that these daughter boards could be used as standalone GM tone generators with the addition of a basic circuit.
Because of scarcity and increased demand, from retro gamers and DIY synth builders, the going price for the old cards is very high. Serge's X1 board compares very favorably to both the Roland and Yamaha cards at a fraction of the cost.
Dream Blaster X1 vs Roland vs Yamaha
The X2 offers extended features, such as flashable wave banks.
Yogi
EDIT: here are the links to the SAM5504 chip used on the X2
-
So I've been working on midi routing while I wait on some parts for adding encoders. After enabling 4 Uart midi interfaces I took a bit of a side trip with another project. The other project is a carrier board for a Dream Synth 2195 based board, the Fluxamasynth (but also suitable for the Serda Shop's S1 or the upcoming X2 Dream Blaster Synth). I had built the board awhile ago and used it as a standalone tone generator with direct midi in; but I included a MB IIC midi TX only circuit with the intent to develop a MB based GM synth at some point. I decided to at least test the 'F88 circuit on the Goom core while I was digging in MIOS32 code.
The current WIP code includes simple routing between DIN midi interfaces and a single USB midi pipe,
- DIN 1 In forwarded to USB
- DIN 2 to Goom Synth
- DIN 3 to Dream Synth.
The handling of USB In is handled a little different,
- USB forwarded to DIN Out 1 (for a basic USB to Midi type interface)
- Channels 1 - 9 forwarded to the Goom engine and Channels 10 - 16 forwarded to the Dream board.
There is also code to selectively layer Goom Channel 1 Note messages with Dream Channel 11 for a very fat sound. ATM it's selected in the source but will be a runtime control. This strange handling is due to my XP box not liking multi USB midi sys ex, can't upload code with more than 1 USB interface enabled :( Even the Bootloader Hold sequence doesn't help. So at least during dev, have to restrict USB usage for easier coms.
It started as a test but really like the GM voices with the Goom, if for nothing else then the drum channel. This 'layering' could also be used with other external synths by adding a IIC Tx only port. Like I said, will have to re-work the USB interfaces adding better routing and also add some CS control of the GM patches and such, along with a better audio mixing circuit.
If there is interest I can document the GM board, but it's not too different than the designs for other waveblaster carrier boards.
Here is my Dropbox with the WIP source and hex build with the 'Layered voices' enabled, but unless you have another synth on IIC 0 there won't be much advantage.
https://www.dropbox.com/sh/7t5s0tp8ajh5f8t/AAD63JClTlGc2FX3TnBGpe8aa?dl=0
Just got to say again how nice it is coding with MIOS32, even for a C noob like me :) Thanks TK!!
Yogi
-
Well I got Program Change messages working, changing between hardcoded patches. Currently only have 4 patches mapped to PC0-3 but these can be loaded into any of the 16 voices. The LCD is displaying the current Patch name on channel 1 with some filter prams.
Here is the patch.c wip, the comments explain the patch structure and how to add patches.
And here is a demo
Yogi
-
Oh very cool panel. Yes agree with your 'top six' prams on the touch pads, as the ADSR settings are more set and forget. Really like how you have it laid out, giving me some good ideas. Something like 10 knobs that directly control prams and a set of 4 knobs toggling between Osc/Filter/Amp for the ADSR settings.
Yesterday got a basic default patch setup function working. ATM the code loads channel 1 at boot but can load a patch on demand. Also changed the LCD routine to show 3 prams, mainly useful for debugging.
Here's the preview projectPATCH.hex with a very bassy range
I'll be adding a Midi send for the patch CC values
Yogi
-
For myself - XP SP3, fails first time after Clean All but compiles fine, and runs, thereafter with either change (Thumb as source or ARM as source=scr/wave.s) to Makefile 2178 2015-05-25. Hex file ~2K bigger (181K) than pre-compiled project.hex (due to MIOS32 core updates since 2015?). Other projects compile without problem but also a little larger.
Yogi
-
Would have to look at examples of morphing for ideas :)
I'm using the Goom Ctrlr Panel now which works for the most part but it's save functions (or the really old Ctrlr version I have to use) are a bit of a mess. No easy way to assign one voice's patch to another voice, some issues with updating when switching between patches and patch names don't work. So by adding a CS to the synth, we are ~ 80% of the way to being able to natively save and recall patches, I think (it's really great coding against MIOS32). Using a MBHP 'F4 Core board is a nice addition to the bare synth, breaks out everything for easy expansion.
With patches saved on the HW we can use Prog Change messages for favorite patches and gain independence from the Computer (although I like the idea of a RPi front end).
For awhile, and maybe still, had planned on using another core running NG for a CS. But a single 'F4 solution is very attractive to me. Even if it's a bit minimal like a Shruthi, we can still control it with midi or, with more effort, directly from the CS.
Anyway, I think I'm getting ahead of myself. Need to get a few encoders hooked up and play some :)
Yogi
-
Just now, Phatline said:
...a 3rd OSC, and i would use it...
but after looking into the code, i think i cant modify it
... dont know assambler
Kind of in the same boat with ARM assembler. Maybe some day...
BUT adding some other stuff like an arp, echo or lfo seems do-able.
-
So here is an open question to all: what would be your preferred CS for this little beast? ATM I'm messing with the source and got a proof of concept LCD display going. It not very useful, just displays the current VCA Level. I'm planning to add some sort of CS controls and patch storage.
I lean towards a knob per voice pram (21 + two toggling switches for the FM and FREQ Md ) and switching between the 16 voices. At the very least will add some sort of midi feedback function (to keep editor softs updated with the local controls).
Just starting but would like to hear opinions,
Yogi
-
7 hours ago, cube48 said:
Thanks a lot! That's really valuable info. I hope to get my build toolchain set correctly so I can try to compile it again.
I'm curious if the values can have decimals/cents. I.e.:6 = 4 semitones
3 = 8 semitones
1.5 = 16 semitones
1.125 = 24 semitones...?
0.75 = 32 semitonesIt can be totally false assumption... I desperately suck at math :-)
Not really sure, but the fractional factors may violate the data type (?)
Also, at one point I was having an issue with the toolchain install that sounds similar to what you are seeing, hex too small. It boiled down to not having one (can't recall which) Env Vari not set correct. I ended up adding all of MIOS32 EVs to my System Variables rather than setting them from the CLI (I'm using XP SP3 and Notepad++ with a Make macro). It was one of the "MBHP_CORE_STM32F4: " specific set I think. I was trying to use the
set MIOS32_GCC_PREFIX=arm-none-eabi....
in the NP++ Make macro but XP was not having it, so ended up with a more permanent setting.
Yogi
-
'Data Protect' should only disable reading from the chip, but should allow erase. There is a recover discussion here:
http://www.microchip.com/forums/m242087.aspx
Don't know if it will help you. Vdd will need to be at least 4.5V for the erase, should be able to set it in MPLab (if you are supplying Vdd from the PICkit).
Yogi
-
So I finally loaded up my local hex build (181K in size) that I wrote about above and it works just as great as the precompiled hex (179K). This was as much a test of my toolchain install (just recently had to set it up again) as a test of the Goom scr.
I assume that the change in size of the two hex files is due to slight changes to the MIOS32 core functions (?)
Yogi
-
Well, the 16f88 is supported by the PICkit 2 and you should be able to program one directly on a breadboard. The biggest problem is if you load a Hex that sets the MCLR to a GPIO or uses timers (that use RB6 or 7), so once the code boots you can't enter PRG mode to verify or erase.
I would advise against trying to 'force feed' Vpp to the chip as you can't control the timing needed and likely kill the chip.
With a fresh chip you should be able to connect the PICkit 2 header, as above without external 13.1V or Vdd, and the PICkit 2 will supply Vdd and Vpp to the chip. If your USB port can't supply the needed current for the PICkit try using a powered hub.
This is a very basic breadboard setup (pretty much what I use with the ICD2) :
https://sites.google.com/site/picf88/16f88---tutorial
Yogi
-
1
-
-
Well, sorry to hear of your troubles. Vcc (vdd) should be no more than 5.5V, so that's the main problem. And I don't think you need the R in there, but I use a ICD2 with a simple header-to-socket board so not sure of the PicKit2. In fact, after checking, the ICD2 has PGM going to RB3 pin 9 (to enter LV Programming Mode), but this signal isn't on the PicKit2. I think the PicKit2 generates the Vpp 13.1v to enter Programming mode with Rb6 and RB7, but Vdd to the chip should never be above 5.5V
http://ww1.microchip.com/downloads/en/DeviceDoc/39607c.pdf
Yogi
-
Very cool :) Love the voice samples, random noise of modern life.
Yogi
-
Good deal, almost done. All 1% 100ppm and highest 'on hand' inventory (at least for US Mouser). I'll send you new BOM :)
Yogi
Done, link sent :)
-
Hi Antichambre, not so much an error, because the values and power ratings are correct. It's just the package style for the Vishay Dale RN60 series, CMF 20 Mil spec at 9.5mm x 3.5mm. The RL07 series is 6mm x 2mm, which is what we normally see size wise for a 1/4w.
The RNs will work but will be tighter in the case. If you like I can go through the BOM and select smaller Rs, preferer Vishay or price (as other brands can be 1/2 the cost of Vishay)?
Yogi
-
A little heads up, just received my parts order, based on the TIA BOM. The resisters are a little oversized, about 3-5mm longer than the average 1/4w package(and wider by about 2mm). It shouldn't be a issue for the board footprints, being vertical mounted, but may be too tall (?) without needing to 'lean' the resistor some.
Anyway, looking forward to the boards
Yogi
-
On 5/19/2015 at 8:42 AM, royal_orchestra said:
Hi,
I have a question about how to realize a combination of a Raspberry Pi and the Midibox Sid.
I made something like a DSP-FX-Unit with a Raspberry PI, Usb-Soundcard, USB-Midiinterface, some Pots, Buttons and a LCD. Everything in a Steel-Case not much bigger than a Guitar-FX-Stompbox. It is running Puredata on Linux, programming is done via LAN. Among other things it is great to connect my Sid V2 to it and add some digital effects to the Sids.Now I wonder how I could add a Sid directly into my Puredata-Box.
I have a few GPIOs left - Could I connect a SID-Module directly to the Raspberry, leaving out the USB->MIDI->Core parts? or connect a Core to the GPIOs and reuse parts of the MB-Sid - Software?
All thoughts, advices or hints are highly appreciated...
best regards
OK sorry for another necro bump, but just ran across another project that directly relates-
https://www.raspberrypi.org/forums/posting.php?mode=reply&f=38&t=110788
So this consumes alot of the GPIO pins, but it may be useful.
Yogi
-
On 7/28/2016 at 3:53 AM, cube48 said:
Problem still persists. I've set up a build environment on another machine (AVLinux, 64bit) and getting similar error. It seems that the source code of Goom port is broken somehow because other midibox apps are being built fine.
Creating object file for wave.s sed: can't read project_build/src/wave.dd: No such file or directory /home/cube48/midibox/mios32/trunk/include/makefile/common.mk:172: recipe for target 'project_build/src/wave.o' failed make: *** [project_build/src/wave.o] Error 2Is anybody else able to build the Goom from source available in MB SVN repository?
Hey don't know if you solved this, but just ran across this same issue in another thread-
It seems that fix was a roll back to an older Makefile. There wasn't a follow up as to if this effected the apps operation, but 'no news is good news' may apply (?)
Yogi
EDIT- OK so I went ahead and tried test builds with the current Makefile and the suggested older version. Both fail on the first try and succeed when re-running make ( with no cleanup). Both .Hex files are 181KB, which is larger then the the 179 KB .hex in ~\release\ STM32F407VG\ in the SVN. Not sure about the 2 KB difference between the SVN and these local builds.
EDIT2- just compared both the 181 KB .hex files with HxD and they are identical. So the changes to the makefile didn't change anything with the build ( but there is still the difference between the SVN version).
-
Very good to hear, I was hoping the Manager works this way. Will setup a foo 'MB TIA' core
If I can hang on to this PC a little longer it would be good. It's a little like an old house, too small and the roof leaks sometimes but the thought of moving is worse. But for day to day use the issues stack up. BTW, still have a W98 box, but it's just for Adlib tracking. Has a YMF719 OPL3 on the mobo; unique old Sony Vaio desktop. Purple case and very non-box shaped; even have the matching Purple KB. So OK, I have a problem 'letting go'
Yogi
-
Well... will have to ask one more question. Does the Manager work, knobs move and such, without a MB TIA connected? I ended up having to install 5.1.9 runtime, which is Very old, to install on this Very old XP box. The Manager opens OK (I think, the graphics look correct), but most controls are grayed out. When I 'play' the keyboard it sends midi Note On/Off messages so that's hopeful. And it detects all the midi interfaces connected.
Also the startup log shows a lot of errors, so I'm afraid MaxMSP 5 is just too old (and this PC also). Seems like time to upgrade
Yogi
-
1024 presets, OK! AND support for dumping via Manager
Will have to install the Max runtime here and play a bit with the Manager. Just this afternoon DLed the older runtime, 6.1.10, for this XP machine.
Yogi
GM5 MIDI thru/split help
in Design Concepts
Posted
In reference to the GM5, you should be fine with: TTL Midi out from GM5 pin into 'HC00 gate(as inverter), it's output to two (or more) other gates (also 'inverters') for two Midi Out DINs. Doesn't have to be 74HC00, just need two 'inverters' per midi out, to buffer. LTC fashion, TTL out ->Buffer (two inverters) ->Midi Out DIN circuit
A "Thru" is connected to the Midi In so it's a split of the TTL level out of the opto. But you want to split a Midi TTL Out so just two-way buffers and DIN circuits.
Yogi