Forum comments in chronological order

Disclaimer: I am not responsible for what people (other than myself) write in the forums. Please report any abuse, such as insults, slander, spam and illegal material, and I will take appropriate actions. Don't feed the trolls.

I was extremely amazed by your hardware chiptune project and now, as if it is possible, I am even more amazed with the Chipophone project. I have absolutely no idea how you fit all that operations on a 38khz interrupt along with the high-level controllers. I would really love to see the code.

Thanks!

jimqode wrote:

Please enlighten me on these chipophone related questions:

1. I guess your output is a ladder DAC. How many bits? 2. Are your oscillators lookup table based? If not, how did you implement the noise?3. Are there any filters in the Chipophone? If so are they implemented in software or are they analog filters?4. At the begging of the Delta video I see you programming a sequence. Is that functionality implemented in the synth uC or MIDI controller chip?

Keep up the good work!

1. The Chipophone uses an 11-bit DAC. That might be overkill, though.

2. No, the waveforms are calculated from the high bits of a counter which is incremented by a frequency value at every sample. For noise, the carry bit from that addition triggers a new noise sample to be generated. Noise is generated by a 15-bit LFSR, which is implemented like this:

ldi r20, 2 lsl r8 rol r9 brvc skip eor r8, r20skip:

The shift register is global, so I never use r8 or r9 for anything else. This makes the code very efficient. I could probably make it even faster, but right now the triangle wave is the bottleneck.

3. Nope, no filters in the Chipophone. There's a simple non-resonant lowpass filter in my Phasor demo, if you're curious about how to implement it efficiently in AVR assembly language.

4. In the synth microcontroller, although it could have been implemented either way. But the synth has a convenient 100 Hz loop for handling vibrato and other stuff, so it was easy to put the sequencer functionality there as well.

can i get the correct schematic as i a a begineer to micro controller i am unable to get the schematic which u have did in text format. i read the comments someone has given the schematic in eagle format but unfotunately io didnt found that. so can u or anyone else mail me the schematic My mail id is azhar.karnalkar@gmail.comthanks in advance. and a great work man.

Two "improvements"1. Ensure the sync_cnt delay is large enough for the initial 4096 PLL clocks to expire so the initial VSCL=1 gets picked up before the VSCL=65 gets set. (I don't know if there's a way to do a waitcnt after the VSCL=1, then somehow get all of the cogs to agree on a new sync_cnt value).2. When setting VSCL also set the pixel counter to 1 (i.e. VSCL = 1<<12 + 1 and VSCL = 1<<12 + 65) so the pixel and frame counters stay in sync.

I may agree with you that most syntax highlighters choose to highlight features that are somewhat uninteresting to the coder, rather than more important elements like '=' vs '==' in c. I would love to see nested parentheses and their contents highlighted in shades that depended on the nesting level, for example.

However, I do disagree strongly on the more general sentiment that syntax highlighting is in itself damaging to comprehension in the long run.

You can train your brain to do a great many things, but to not use the inherent skills of the brain is a waste of "talent" and time. If you can leverage peoples' highly developed visual senses to make the semantics more clear, this, it seems to me, is a rational choice, not a crutch. Again, we can talk about whether common syntax highlighters highlight useful things or not, but the notion that syntax can be aided by visual formatting, including color, is something I believe in.

You can do this via indenting, as everybody does, and/or color choice, as syntax highlighters try to do. I would even go further off the syntax-highlighting deep end and propose using larger fonts for higher-level structural elements like class declarations. As John Carmack said in a recent tweet: "Syntax highlighted code is better than raw text, but still not as good as, say, a typical Wikipedia page. Room for structural formatting."

Yes, Brethren... also, the other most common use of the word Fratres is "Orate Fratres", a call to prayer from Catholic liturgy.

Does anyone happen to know the origin of the piece, and/or why it has the name Fratres? I've never come across this in my readings about Part and I am very curious, it being one of my favorite pieces to listen to (and play).Best to all,karl@freefriends.org

Fratres means brethren (or brothers). Hence when priests or ministers get together it is called a Fraternity (now that we have women priests it should be a Maternity!)The pulses on the claves/percussion is a Renaiassance call to attention/prayer that the monks (or brothers) would have played using wooden semantra - which prefigured the use of bells in the Eastern Church)

Two "improvements"1. Ensure the sync_cnt delay is large enough for the initial 4096 PLL clocks to expire so the initial VSCL=1 gets picked up before the VSCL=65 gets set. (I don't know if there's a way to do a waitcnt after the VSCL=1, then somehow get all of the cogs to agree on a new sync_cnt value).2. When setting VSCL also set the pixel counter to 1 (i.e. VSCL = 1<<12 + 1 and VSCL = 1<<12 + 65) so the pixel and frame counters stay in sync.

Eric Ball(I need to go back and tweak my multi-cog driver.)

Thank you!

1. Yes, this can be done when the video signal clock is an integer multiple of the system clock (such as when FRQA is $10000000). Otherwise, it's important that CTRA is assigned simultaneously in all cogs, and then you need both of the waitcnts.

2. The pixel counter is always reset when a new frame begins, so this is not necessary. It may or may not make the code easier to understand.

Nice work Linus!I have no experience with this, but wouldn't it be possible just to connect an HDMI to DVI adapter followed by a DVI to VGA adapter to the HDMI port on the BB?

/G

no it would not, the only signal that is coming through the HDMI port is digital. The way most DVI to VGA adapters work is by taking the analog portion of DVI and wire it to VGA. The alternative method to this would be to buy an actual digital to analog converter. However this method would cost more than the Beagleboard itself.