Inspired by a video that Linus posted, (The Chipophone) I started hunting down everything I could read on Propeller Midi and discovered this project buried in the forums.
Inspired by a video that Linus posted, (The Chipophone) I started hunting down everything I could read on Propeller Midi and discovered this project buried in the forums.
Hi Jeff
thanks for making an article and a video... it's months that I'm "on the verge" of making a video for youtube, but I never decide to follow the intention (I didn't even answer to Joe's offer... sorry Joe, and thanks to you too!).
two things:
- be sure to use the latest version (I think the version linked in the instructables article is not), not only because of the extra output options (SPDIF and StereoDuty), but also because having debug disabled makes it MUCH more responsive in terms of key-to-sound latency.
- as I mentioned in a previous post, I have 8 MIDI recordings inside my QY-20 which are supposed to "show off" the 8 presets: I can translate them to mid files, pack and send to you if you like (now where did I put that old MS-DOS utility for the QY-20? )
I'll update the "source" link on the "Tribute" page of the Instructable to point to the lastest version. I'm pretty sure I'm using it with the PMC binary already.
One of the things that made possible this project in the first place, apart from the excellent attitude of this community at sharing code and ideas, is your own "Propeller Cookbook": that's what turned me from "uh? this chip is weird!" to "aaah, this chip is wonderful!" a couple of years ago!
I'm trying to get the MIDI files on my PC by MIDI cable, but Reaper keeps on eating the first notes of the sequence. hmm
Meanwhile, here's the recorded output of these files when replayed from QY20 into the MIDI input of the DIY board mentioned on post #16 (using StereoSpatializer output driver so it's noisy, will redo recordings with SPDIF when I have a bit more time).
@AntoineDoinel Those example mp3s sounds cool!
I havn't tried this myself yet, so I can't tell if the aliasing distortion comes from the synth or if it's your recording equipment. I would guess it comes from converting 31 kHz to 44.1 or 48 kHz spdif.
It might even be a better idea to change the sample rate of SIDcog to half the final sample rate to get rid of aliasing distortion in the resample stage.
@AntoineDoinel Those example mp3s sounds cool!
I havn't tried this myself yet, so I can't tell if the aliasing distortion comes from the synth or if it's your recording equipment. I would guess it comes from converting 31 kHz to 44.1 or 48 kHz spdif.
It might even be a better idea to change the sample rate of SIDcog to half the final sample rate to get rid of aliasing distortion in the resample stage.
/Johannes
My equipment is a plain Audigy 2 ZS with the 5.25" front panel expansion, nothing fancy. Hmmm and there's a large ventilator still blowing air and EMI on the PC side left open, as the CPU fan needed a little help from her big sister this summer. :cool:
The filter of that board is a >4x the cutoff freq of the DemoBoard (it's R=2.2K C=10n, plus 10u decoupling), so eventually more artifacts from that samplerate mismatch will pass thru.
Next time better use the Zoom MRS-8 again for recording, unless it's SPDIF. Not the best as a reference, it uses a proprietary compression algorithm internally, but at least electrical interferences can be kept down. It can use batteries too, if required.
I agree, it would be good to have outputs matched to an integer ratio. And being based on the same crystal, they should not be subject to fractional clock "slipping".
My initial thought was doing the opposite, i.e. adapt the drivers to SIDcog rate. That because SIDcog got that rate because it's the best that can be obtained while tightly fitting all the required calculations, and it would seem a waste to me to "waste" cycles slowing it down to match the output driver, instead of the opposite.
Now the StereoSpatializer is far too intricate for me to hack, and it has quite a lot of math going on inside, so I doubt it can be modified for higher rate. But that could be tried on the other drivers, including the new ones created recently by Pik33.
Still to be tested (I wanted to avoid the requirement for non-standard circuitry), the "good ole" passive mixer with direct SID outputs!
I'll update the "source" link on the "Tribute" page of the Instructable to point to the lastest version. I'm pretty sure I'm using it with the PMC binary already.
Thanks
Jeff
Hi Jeff,
Here are the MIDI files used to generate the previously posted MP3s.
Unfortunately I had an old firmware loaded on the red PCB board, after updating I realized that some patches (expecially the toy piano) sounded definitely worst than before now: if it works, break it!
By looking at the source I see DumpPatch() is still called on sustain pedal release.
If you want to make your own mods permanent, that is the current makeshift method for saving sounds: after you play with knobs, push and release sustain, and the current parameters will be dumped to the debug serial. Cut that output and paste it to replace one of the factory presets in patch.spin. Then recompile the binary. Sorry, I know I should be beaten for having devised a similar monstruosity...
...but it was supposed to be temporary (I know, upper EEPROM is waiting with open arms!).
Thanks pik33, I have to give it a try.
Basically, either I need to use a time multiplexing trick to get 4 channels from L/R, or I need a driver that's mixing 4 sources before the output (like StereoSpatializer).
Do you think something like this could work, eventually at a lower sample rate?
Replacing your code for HUB reads, this section should be some 16 clocks slower (80 vs 64).
It's a simple 4:2 mixer to fixed panpot positions, same positions I'm using in StereoSpatializer as "angles".
DAT
' assuming 4 signed long outputs from SIDs
' pointed by sid0ptr, sid1ptr, sid2ptr, sid3ptr
' ATTEN = constant in [0..n]
' should never clip except when ATTEN = 0
loop rdlong s0, sid0ptr
sar s0, #(1+ATTEN)
mov lsample, s0 ' L = 0.50*s0
rdlong s3, sid3ptr
sar s3, #(1+ATTEN)
mov lsample, s3 ' R = 0.50*s3
rdlong s1, sid1ptr
sar s1, #(1+ATTEN)
adds lsample, s1 ' L = 0.50*s0 + 0.50*s1
rdlong s2, sid2ptr
sar s2, #(1+ATTEN)
adds lsample, s2 ' R = 0.50*s2 + 0.50*s3
sar s2, #1
adds lsample, s2 ' L = 0.50*s0 + 0.50*s1 + 0.25*s2
sar s1, #1
adds rsample, s1 ' R = 0.25*s1 + 0.50*s2 + 0.50*s3
sar s0, #1
adds lsample, s0 ' L = 0.75*s0 + 0.50*s1 + 0.25*s2 + 0.00*s3
sar s3, #1
adds rsample, s3 ' R = 0.00*s0 + 0.25*s1 + 0.50*s2 + 0.75*s3
'- noise shaping
'- clipping to min/max (if required)
'- output to counters
jmp #loop
There is a bug in SIDCog - it doesn't output sid sample to HUB Ram as expected.
Here you can find a ugly hacked sidcog version, using my driver instead duty dac:
IIRC the output is not working from SPIN because of that, but write of sample to HUB was in place. Once located, I had the output drivers picking it up from there. I also had to flip sign because StereoSpatializer expected it differently, but that can be done preserving the original functionality (the direct output on a pin), by only changin the order of instruction in SIDcog output section.
Adding a code to the driver's main loop is not a good idea because it is time critical. Whem adding more code, you will have to lower sampling frequency. Thiis will lower sound quality. The higher sampling freq, the better is the sound. Best results are available with extremally overclocked prop (@ 118 MHz it can give 10x oversampling instead of 7x)
This driver plays samples from a buffer, so I think mixing and stereo spatializing could be done before placing samples in this buffer. You can use stereo spatializer code and then put these samples to the buffer instead of putting it to the output. Cost: 1 additional cog.
SidCOG was hacked to get output samples in its proper place (SPIN compiler places LONG first, so offset to this var had to be changed in SIDCog's PASM code) and to slightly change its output frequency to fit a driver needs.
Edit: 16 clocks slower.. you can try to lower oversampling from 7x to 6x
Set delay=302 instead of 259
overval=6 instead of 7
(overval*delay should be something about 1814 @ 80MHz , 2267@100 MHz, 2675@118 MHz-max clock possible with my prop)
@pik33
Every now and then people messages me about that SIDsample doesn't seem to work. I always reply that "I have verified that it actually works". The reason is that whenever I release a new version of SIDcog, I test it with my chip tune player. The oscilloscope always seem to work as supposed, so that "proves" that SIDsample works right?!
I verified this today using SIDcog v1.3 from OBEX and it still works as intended. I have tested it with both Propeller Tool and BST, it works the same. I have tested it with different combinations of optimization options in BST, it always seems to work. This is a mystery to me. Sadly I don't have the time to debug this right now.
It has been wrong ALL the time (since 2009). The reason it works in my chip tune player is because my Oscilloscope initializes with "SID base address + 28" and not "@SIDSample".
I will fix this in the next release of SIDcog. And sorry to all you guys that have been struggling with this and sent me a lot of annoying messages.
sub tempValue, #8 '<----- changed here
wrlong r1, tempValue '| Write the sample to hub ram
near the end of SidCog PASM code. I had to fix this because it didn't play anything via SidSample. So I had to check what is wrong with SidCog code.
The compiler places longs first. Par points to the first SID register. It is byte, so LONGS are placed before them. This means not add #28, but sub #8...
I can't get the code to compile with the Propeller tool or BST. Getting this error : Expected "," or end of line (Propeller Tool). I am starting the compile from the "SidSynth.spin" file.
I can't get the code to compile with the Propeller tool or BST. Getting this error : Expected "," or end of line (Propeller Tool). I am starting the compile from the "SidSynth.spin" file.
Am I missing some code?
Thanks,
Tom
Hi Tom
You need BST, Propeller Tool has no support for preprocessor directives.
Can you post more details, i.e. the line where "," is expected by BST?
Also, are you using the archive from post #27? No code should be missing from that, except for the PC GUI interface (which is absolutely not required).
Using that archive and BST :
SidSynth - Error at (211,2) Expected Unique Name Constant or "("
SidSynth(212,3) Error : Symbol BUFFER_SIZE is already defined!
SidSynth - Error at (334,1) Expected Object definition
Would be nice if I could cut and paste the error messages in BST. Is there a way to do this?
A simple schematic of the sound hardware would also be good.
Thanks,
Tom
Hi Tom
I've downloaded the archive from post #27 to recheck it with BST, and apart from lots of warnings it seems to compile without problems. This is SIDsynth.spin just loaded, pressing F8:
The only optimization option that needs to be disabled in BST is "Eliminate unused SPIN methods", otherwise I get a warning saying "this binary will not run". That option is usually excellent to recover more space for code, but I noticed it also failed a few other times with completely different projects, so I guess it's a bug in BST.
The two circuits are more or less equivalent (note that input pins are upside down in one of the schematics): the 1K series resistor in the one from OBEX is used because that one it's pulling up to +5V, while the one from Jeff use pulls up the collector to +3.3V. So the only relevant difference is the pull-down on the base of the output transistor, which is good idea IMHO, as it should avoid any noise on the base when no current is flowing in the input side.
Here I'm going on a wild guess, but I think that (relatively) low value on the base is adequate since it's pulling down the second element of a darlington pair. I've made circuits with single BJT optoisolators as well, like the 6N27 or 6N35, and in that case a value >100K seems to work ok.
This is also the reason why there's not a single "suggested" circuit, we've used a large variety of optoisolators depending on what we had available (including some H11L1 in my case). So I'd say that the one proposed by Jeff can be considered "the good one" for the reasons listed above: better noise immunity, direct interface to +3.3V, better switching due to the darlington transistor... and availability in mini-kit form from him!
Now I would have tried pre-compiling some binaries for your hardware, with both true or inverting serial as I did earlier in the thread, so you could test them while you solve the problem with BST. But if you're following Jeff's schematics and using the same hardware and pins, the binary file he posted on Instructables should work right away. :blank: hmmm
So I tried manually edit out the preprocessor directives, but the more I removed, the more errors I got (must not have been doing it correctly). I am using version 0.19.3 of the BST tool.
I was going to load Jeff's binary, but it had a "bin" extension and BST was expecting a "binary" extension.
I am running this on a 64 bit Windows 7 computer. Perhaps I'll try in XP.
So I tried manually edit out the preprocessor directives, but the more I removed, the more errors I got (must not have been doing it correctly). I am using version 0.19.3 of the BST tool.
I was going to load Jeff's binary, but it had a "bin" extension and BST was expecting a "binary" extension.
I am running this on a 64 bit Windows 7 computer. Perhaps I'll try in XP.
--tom
Do you have the "Non-Parallax compatible Extensions" box checked under Compiler Preferences / Optimizations?
When building that project, I believe I also ran into yet another "Midi-In" variation in addition to the one which you pointed out in the Obex.
It's interesting to me that you had trouble with this as the circuit was built with the same board you are using here. Were you able to get it working?
I was able to get the circuit working, though there was a unpleasant amount of distortion in the output. I will try again using the S/PDIF output. I have an inexpensive D/A converter I purchased to connect my Apple TV to my stereo...it has a coax input.
I was unable to get the MIDI in to work via input P1 (I connected through the SD interface header -- I think the first 4 pins, left to right, are P0, P1, P2, P3).
When I connected through P12 via the TV Experimenters port and changed the appropriate line in the code, that's when it started working. So either there is additional circuitry on the Quick VGA + board between pin P1 and the header, or there is something else going on. I could not find a schematic for the SD header on the Quick VGA + to confirm.
The turning point in getting this to work was to turn on "Non-Parallax compatible Extensions" in the BST compiler preferences.
Not sure why there needs to be so many variations on how to do MIDI in and audio. At least some explanation about when to use different circuits would be helpful.
I mapped 8 of the controls on my MIDI keyboard to the 8 CC parameters. The results were a bit odd. I left the control range set to the default (0 to 7F hex, I think), which may not be appropriate for some of the parameters.
I was also getting varying volume levels based on the patch selected.
A nice update which I might try, is to add connections for 8 knobs directly to the board. Then I could use this device with a small USB MIDI keyboard that does not have control knobs, like my Akai MPK25. This would make it more of a turnkey system that would be easier to use for making music.
When building that project, I believe I also ran into yet another "Midi-In" variation in addition to the one which you pointed out in the Obex.
It's interesting to me that you had trouble with this as the circuit was built with the same board you are using here. Were you able to get it working?
The demonstration you saw me use in the video was on the "experimenter's port". There is no reason why (other than code reasons) why it shouldn't have also worked on the SDmodule connection points. Those points are simply traces directly back to P0..P3.
BTW, here's my last reference schematic for the VGAplus. The 10k resistors should probably be notated on the image that they are included on the SDmodule side of the circuit.
Glad you got it working! My bad, I was so used to having all the optimizations checked in BST that I didn't think about those being disabled in a fresh install...
The range of the controls is always scaled to the full 00h..7Fh input range. So for example, the waveform selection tries to mimic a five position switch by dividing the pot travel in 5 equal angles. If you look at the source, you can see that symmetry of the controls is almost an obsession!
That said, some controls might still not act as you'd expect because of the scaling constants used (i.e. the VCF env amount, which is also bipolar), or because the logic is not immediately apparent (the interaction between some positions of the two waveform select knobs, there is an explanation in the source but I don't know if it's clear enough).
I used a MIDI keyboard with 16 knobs, and the functions can also be doubled by using program change 0..7 or 8..15 to switch between sets IIRC, for a total of 32 controls.
If you were to use less than 16, choosing a subset is obviously is a matter of tastes.
It would be nice to use rotary encoders with LED rings instead of potentiometers, because even with as few as 4, you could then switch control sections and still have the correct feedback.
BTW did you mean the LPK25? Because the MPK25 shows 12 knobs in the pics...
Accounting for +3.3V logic level, the voltage divider can be changed to 220R/100R insted of 330R/100R.
But in the end I just used the TV dac in the demo board, biasing the other pins to get a similar ratio, and it worked well and reliably.
My settings/config
- S/PDIF on pin 13
- MIDI RX on pin 12
- Separate SID outputs off (does this matter?)
- #define USE_SPDIF
These are active, though they shouldn't make any difference
AUDL_PIN = 11
AUDR_PIN = 10
I got the S/PDIF working. I changed the resistor to 220 ohms. I confirmed that it worked by running the _test_SPDIF_Coax program. All good so far.
Tested with the test_SPDIF_TDM program. That works also.
Loaded "SIDSynth.spin"....I'm getting no sound output. I tested my MIDI keyboard with a MIDI monitor program on my iPhone.
I ran a step sequencer program on the iPhone, MIDI out to the Prop. No sound.
I'm wondering if there are any parameter changes that I am missing.
Is there a way to confirm that the Prop is getting the MIDI signal?
More info
-- switched the output back to STDUTY and recompiled. Working and I see the channel gating on the LEDs
-- switched the output back to SPDIF and recompiled. No other changes. No output and no feedback on LEDs.
So, MIDI data is getting through, because it works in STDUTY mode. When I change back to SPDIF, nothing.
As I mentioned before, when I run the SPIF test program, I hear the output, so the SPDIF output is working.
Something is getting lost in the middle. Have not figured out how to run debug. That will be next.
Glad you got it working! My bad, I was so used to having all the optimizations checked in BST that I didn't think about those being disabled in a fresh install...
Comments
I've written an Instructable using this code and hopefully this project will get some very well deserved attention.
http://www.instructables.com/id/Building-a-Retro-Synthesizer-with-the-Pocket-Mini-/
Jeff
Hi Jeff
thanks for making an article and a video... it's months that I'm "on the verge" of making a video for youtube, but I never decide to follow the intention (I didn't even answer to Joe's offer... sorry Joe, and thanks to you too!).
two things:
- be sure to use the latest version (I think the version linked in the instructables article is not), not only because of the extra output options (SPDIF and StereoDuty), but also because having debug disabled makes it MUCH more responsive in terms of key-to-sound latency.
- as I mentioned in a previous post, I have 8 MIDI recordings inside my QY-20 which are supposed to "show off" the 8 presets: I can translate them to mid files, pack and send to you if you like (now where did I put that old MS-DOS utility for the QY-20?
Alessandro
I'll update the "source" link on the "Tribute" page of the Instructable to point to the lastest version. I'm pretty sure I'm using it with the PMC binary already.
Thanks
Jeff
Congrats on SIDcog synth being on Hackaday http://hackaday.com/2012/10/18/creating-a-midi-synth-from-a-commodore-sid/
One of the things that made possible this project in the first place, apart from the excellent attitude of this community at sharing code and ideas, is your own "Propeller Cookbook": that's what turned me from "uh? this chip is weird!" to "aaah, this chip is wonderful!" a couple of years ago!
I'm trying to get the MIDI files on my PC by MIDI cable, but Reaper keeps on eating the first notes of the sequence. hmm
Meanwhile, here's the recorded output of these files when replayed from QY20 into the MIDI input of the DIY board mentioned on post #16 (using StereoSpatializer output driver so it's noisy, will redo recordings with SPDIF when I have a bit more time).
Alessandro
Those example mp3s sounds cool!
I havn't tried this myself yet, so I can't tell if the aliasing distortion comes from the synth or if it's your recording equipment. I would guess it comes from converting 31 kHz to 44.1 or 48 kHz spdif.
It might even be a better idea to change the sample rate of SIDcog to half the final sample rate to get rid of aliasing distortion in the resample stage.
/Johannes
Jeff
http://forums.parallax.com/showthread.php?141346-Yet-another-wave-player-now-NCO-based-and-noise-%28almost%29-free
There is a bug in SIDCog - it doesn't output sid sample to HUB Ram as expected.
Here you can find a ugly hacked sidcog version, using my driver instead duty dac:
http://forums.parallax.com/showthread.php?140767-A-new-topic-for-vga-%28not-only%29-sid-player
My equipment is a plain Audigy 2 ZS with the 5.25" front panel expansion, nothing fancy. Hmmm and there's a large ventilator still blowing air and EMI on the PC side left open, as the CPU fan needed a little help from her big sister this summer. :cool:
The filter of that board is a >4x the cutoff freq of the DemoBoard (it's R=2.2K C=10n, plus 10u decoupling), so eventually more artifacts from that samplerate mismatch will pass thru.
Next time better use the Zoom MRS-8 again for recording, unless it's SPDIF. Not the best as a reference, it uses a proprietary compression algorithm internally, but at least electrical interferences can be kept down. It can use batteries too, if required.
I agree, it would be good to have outputs matched to an integer ratio. And being based on the same crystal, they should not be subject to fractional clock "slipping".
My initial thought was doing the opposite, i.e. adapt the drivers to SIDcog rate. That because SIDcog got that rate because it's the best that can be obtained while tightly fitting all the required calculations, and it would seem a waste to me to "waste" cycles slowing it down to match the output driver, instead of the opposite.
Now the StereoSpatializer is far too intricate for me to hack, and it has quite a lot of math going on inside, so I doubt it can be modified for higher rate. But that could be tried on the other drivers, including the new ones created recently by Pik33.
Still to be tested (I wanted to avoid the requirement for non-standard circuitry), the "good ole" passive mixer with direct SID outputs!
Alessandro
Hi Jeff,
Here are the MIDI files used to generate the previously posted MP3s.
Unfortunately I had an old firmware loaded on the red PCB board, after updating I realized that some patches (expecially the toy piano) sounded definitely worst than before now: if it works, break it!
By looking at the source I see DumpPatch() is still called on sustain pedal release.
If you want to make your own mods permanent, that is the current makeshift method for saving sounds: after you play with knobs, push and release sustain, and the current parameters will be dumped to the debug serial. Cut that output and paste it to replace one of the factory presets in patch.spin. Then recompile the binary. Sorry, I know I should be beaten for having devised a similar monstruosity...
...but it was supposed to be temporary (I know, upper EEPROM is waiting with open arms!).
Alessandro
It looks like we just got "Featured" on Instructables, so more folks will see this project...
Jeff
Thanks pik33, I have to give it a try.
Basically, either I need to use a time multiplexing trick to get 4 channels from L/R, or I need a driver that's mixing 4 sources before the output (like StereoSpatializer).
Do you think something like this could work, eventually at a lower sample rate?
Replacing your code for HUB reads, this section should be some 16 clocks slower (80 vs 64).
It's a simple 4:2 mixer to fixed panpot positions, same positions I'm using in StereoSpatializer as "angles".
DAT ' assuming 4 signed long outputs from SIDs ' pointed by sid0ptr, sid1ptr, sid2ptr, sid3ptr ' ATTEN = constant in [0..n] ' should never clip except when ATTEN = 0 loop rdlong s0, sid0ptr sar s0, #(1+ATTEN) mov lsample, s0 ' L = 0.50*s0 rdlong s3, sid3ptr sar s3, #(1+ATTEN) mov lsample, s3 ' R = 0.50*s3 rdlong s1, sid1ptr sar s1, #(1+ATTEN) adds lsample, s1 ' L = 0.50*s0 + 0.50*s1 rdlong s2, sid2ptr sar s2, #(1+ATTEN) adds lsample, s2 ' R = 0.50*s2 + 0.50*s3 sar s2, #1 adds lsample, s2 ' L = 0.50*s0 + 0.50*s1 + 0.25*s2 sar s1, #1 adds rsample, s1 ' R = 0.25*s1 + 0.50*s2 + 0.50*s3 sar s0, #1 adds lsample, s0 ' L = 0.75*s0 + 0.50*s1 + 0.25*s2 + 0.00*s3 sar s3, #1 adds rsample, s3 ' R = 0.00*s0 + 0.25*s1 + 0.50*s2 + 0.75*s3 '- noise shaping '- clipping to min/max (if required) '- output to counters jmp #loopIIRC the output is not working from SPIN because of that, but write of sample to HUB was in place. Once located, I had the output drivers picking it up from there. I also had to flip sign because StereoSpatializer expected it differently, but that can be done preserving the original functionality (the direct output on a pin), by only changin the order of instruction in SIDcog output section.
This driver plays samples from a buffer, so I think mixing and stereo spatializing could be done before placing samples in this buffer. You can use stereo spatializer code and then put these samples to the buffer instead of putting it to the output. Cost: 1 additional cog.
SidCOG was hacked to get output samples in its proper place (SPIN compiler places LONG first, so offset to this var had to be changed in SIDCog's PASM code) and to slightly change its output frequency to fit a driver needs.
Edit: 16 clocks slower.. you can try to lower oversampling from 7x to 6x
Set delay=302 instead of 259
overval=6 instead of 7
(overval*delay should be something about 1814 @ 80MHz , 2267@100 MHz, 2675@118 MHz-max clock possible with my prop)
Every now and then people messages me about that SIDsample doesn't seem to work. I always reply that "I have verified that it actually works". The reason is that whenever I release a new version of SIDcog, I test it with my chip tune player. The oscilloscope always seem to work as supposed, so that "proves" that SIDsample works right?!
I verified this today using SIDcog v1.3 from OBEX and it still works as intended. I have tested it with both Propeller Tool and BST, it works the same. I have tested it with different combinations of optimization options in BST, it always seems to work. This is a mystery to me. Sadly I don't have the time to debug this right now.
It has been wrong ALL the time (since 2009). The reason it works in my chip tune player is because my Oscilloscope initializes with "SID base address + 28" and not "@SIDSample".
I will fix this in the next release of SIDcog. And sorry to all you guys that have been struggling with this and sent me a lot of annoying messages.
/Johannes
sub tempValue, #8 '<----- changed here wrlong r1, tempValue '| Write the sample to hub ramnear the end of SidCog PASM code. I had to fix this because it didn't play anything via SidSample. So I had to check what is wrong with SidCog code.
The compiler places longs first. Par points to the first SID register. It is byte, so LONGS are placed before them. This means not add #28, but sub #8...
Am I missing some code?
Thanks,
Tom
Hi Tom
You need BST, Propeller Tool has no support for preprocessor directives.
Can you post more details, i.e. the line where "," is expected by BST?
Also, are you using the archive from post #27? No code should be missing from that, except for the PC GUI interface (which is absolutely not required).
Using that archive and BST :
SidSynth - Error at (211,2) Expected Unique Name Constant or "("
SidSynth(212,3) Error : Symbol BUFFER_SIZE is already defined!
SidSynth - Error at (334,1) Expected Object definition
Would be nice if I could cut and paste the error messages in BST. Is there a way to do this?
--tom
http://www.instructables.com/files/deriv/F48/5U0C/H8CVHX0O/F485U0CH8CVHX0O.LARGE.jpg
Which is from Jeff Ledger's article on Instructables :
http://www.instructables.com/id/Building-a-Retro-Synthesizer-with-the-Pocket-Mini-/
Which does not appear to work when I use it with my "Quick VGA+" QuickStart shield.
And it is somewhat different from the MIDI in circuit that is bundled with the "MIDI in" OBEX object :
http://obex.parallax.com/objects/229/
A simple schematic of the sound hardware would also be good.
Thanks,
Tom
Hi Tom
I've downloaded the archive from post #27 to recheck it with BST, and apart from lots of warnings it seems to compile without problems.
This is SIDsynth.spin just loaded, pressing F8:
The only optimization option that needs to be disabled in BST is "Eliminate unused SPIN methods", otherwise I get a warning saying "this binary will not run". That option is usually excellent to recover more space for code, but I noticed it also failed a few other times with completely different projects, so I guess it's a bug in BST.
The two circuits are more or less equivalent (note that input pins are upside down in one of the schematics): the 1K series resistor in the one from OBEX is used because that one it's pulling up to +5V, while the one from Jeff use pulls up the collector to +3.3V. So the only relevant difference is the pull-down on the base of the output transistor, which is good idea IMHO, as it should avoid any noise on the base when no current is flowing in the input side.
Here I'm going on a wild guess, but I think that (relatively) low value on the base is adequate since it's pulling down the second element of a darlington pair. I've made circuits with single BJT optoisolators as well, like the 6N27 or 6N35, and in that case a value >100K seems to work ok.
This is also the reason why there's not a single "suggested" circuit, we've used a large variety of optoisolators depending on what we had available (including some H11L1 in my case). So I'd say that the one proposed by Jeff can be considered "the good one" for the reasons listed above: better noise immunity, direct interface to +3.3V, better switching due to the darlington transistor... and availability in mini-kit form from him!
Now I would have tried pre-compiling some binaries for your hardware, with both true or inverting serial as I did earlier in the thread, so you could test them while you solve the problem with BST. But if you're following Jeff's schematics and using the same hardware and pins, the binary file he posted on Instructables should work right away. :blank: hmmm
#ifdef USE_STSPAT
BUFFER_SIZE = $0800 '$1000 'TODO: hack SSP for dynamic buffer size?!?
#else
BUFFER_SIZE = $0002
#endif
The second error was that BUFFER_SIZE had already been defined, which would make sense if BST was not interpreting the preprocessor directives.
The third error was on the IFDEF line in this snippet of code :
OBJ''### MODULES ###
'COG 0 running SPIN init/main
serial : "FullDuplexSerial" '<- shut off during init, replaced by audio output (COG1)
#ifdef USE_STSPAT
stspat : "StereoSpatializer" 'COG 1, running mixer/FX/output
#endif
So I tried manually edit out the preprocessor directives, but the more I removed, the more errors I got (must not have been doing it correctly). I am using version 0.19.3 of the BST tool.
I was going to load Jeff's binary, but it had a "bin" extension and BST was expecting a "binary" extension.
I am running this on a 64 bit Windows 7 computer. Perhaps I'll try in XP.
--tom
Do you have the "Non-Parallax compatible Extensions" box checked under Compiler Preferences / Optimizations?
--tom
When building that project, I believe I also ran into yet another "Midi-In" variation in addition to the one which you pointed out in the Obex.
It's interesting to me that you had trouble with this as the circuit was built with the same board you are using here. Were you able to get it working?
This is the audio circuit being used by the VGAplus board. (X2 for R/L channel)
https://www.dropbox.com/sh/qwhixzvtlrvp1u1/_rcN6Ncv27/Schematics#f:simple_audio_circuit.JPG
Jeff
I was able to get the circuit working, though there was a unpleasant amount of distortion in the output. I will try again using the S/PDIF output. I have an inexpensive D/A converter I purchased to connect my Apple TV to my stereo...it has a coax input.
I was unable to get the MIDI in to work via input P1 (I connected through the SD interface header -- I think the first 4 pins, left to right, are P0, P1, P2, P3).
When I connected through P12 via the TV Experimenters port and changed the appropriate line in the code, that's when it started working. So either there is additional circuitry on the Quick VGA + board between pin P1 and the header, or there is something else going on. I could not find a schematic for the SD header on the Quick VGA + to confirm.
The turning point in getting this to work was to turn on "Non-Parallax compatible Extensions" in the BST compiler preferences.
Not sure why there needs to be so many variations on how to do MIDI in and audio. At least some explanation about when to use different circuits would be helpful.
I mapped 8 of the controls on my MIDI keyboard to the 8 CC parameters. The results were a bit odd. I left the control range set to the default (0 to 7F hex, I think), which may not be appropriate for some of the parameters.
I was also getting varying volume levels based on the patch selected.
A nice update which I might try, is to add connections for 8 knobs directly to the board. Then I could use this device with a small USB MIDI keyboard that does not have control knobs, like my Akai MPK25. This would make it more of a turnkey system that would be easier to use for making music.
--tom
The demonstration you saw me use in the video was on the "experimenter's port". There is no reason why (other than code reasons) why it shouldn't have also worked on the SDmodule connection points. Those points are simply traces directly back to P0..P3.
BTW, here's my last reference schematic for the VGAplus. The 10k resistors should probably be notated on the image that they are included on the SDmodule side of the circuit.
https://www.dropbox.com/sh/qwhixzvtlrvp1u1/_rcN6Ncv27/Schematics#f:pmc_core_schematic_revJ.JPG
Jeff
--tom
Glad you got it working! My bad, I was so used to having all the optimizations checked in BST that I didn't think about those being disabled in a fresh install...
The range of the controls is always scaled to the full 00h..7Fh input range. So for example, the waveform selection tries to mimic a five position switch by dividing the pot travel in 5 equal angles. If you look at the source, you can see that symmetry of the controls is almost an obsession!
That said, some controls might still not act as you'd expect because of the scaling constants used (i.e. the VCF env amount, which is also bipolar), or because the logic is not immediately apparent (the interaction between some positions of the two waveform select knobs, there is an explanation in the source but I don't know if it's clear enough).
I used a MIDI keyboard with 16 knobs, and the functions can also be doubled by using program change 0..7 or 8..15 to switch between sets IIRC, for a total of 32 controls.
If you were to use less than 16, choosing a subset is obviously is a matter of tastes.
It would be nice to use rotary encoders with LED rings instead of potentiometers, because even with as few as 4, you could then switch control sections and still have the correct feedback.
BTW did you mean the LPK25? Because the MPK25 shows 12 knobs in the pics...
For the SPDIF output, I took this as reference:
http://www.epanorama.net/documents/audio/spdif.html
(scroll down to the one called "Simplest TTL to S/PDIF coax interface").
Accounting for +3.3V logic level, the voltage divider can be changed to 220R/100R insted of 330R/100R.
But in the end I just used the TV dac in the demo board, biasing the other pins to get a similar ratio, and it worked well and reliably.
Alessandro
My settings/config
- S/PDIF on pin 13
- MIDI RX on pin 12
- Separate SID outputs off (does this matter?)
- #define USE_SPDIF
These are active, though they shouldn't make any difference
AUDL_PIN = 11
AUDR_PIN = 10
I got the S/PDIF working. I changed the resistor to 220 ohms. I confirmed that it worked by running the _test_SPDIF_Coax program. All good so far.
Tested with the test_SPDIF_TDM program. That works also.
Loaded "SIDSynth.spin"....I'm getting no sound output. I tested my MIDI keyboard with a MIDI monitor program on my iPhone.
I ran a step sequencer program on the iPhone, MIDI out to the Prop. No sound.
I'm wondering if there are any parameter changes that I am missing.
Is there a way to confirm that the Prop is getting the MIDI signal?
More info
-- switched the output back to STDUTY and recompiled. Working and I see the channel gating on the LEDs
-- switched the output back to SPDIF and recompiled. No other changes. No output and no feedback on LEDs.
So, MIDI data is getting through, because it works in STDUTY mode. When I change back to SPDIF, nothing.
As I mentioned before, when I run the SPIF test program, I hear the output, so the SPDIF output is working.
Something is getting lost in the middle. Have not figured out how to run debug. That will be next.
--tom