MUFF WIGGLER Forum Index
 FAQ & Terms of UseFAQ & Terms Of Use   Wiggler RadioMW Radio   Muff Wiggler TwitterTwitter   Support the site @ PatreonPatreon 
 SearchSearch   RegisterSign up   Log inLog in 
WIGGLING 'LITE' IN GUEST MODE

[Build] Dervish - SMT Spin FV-1 DSP fx module
MUFF WIGGLER Forum Index -> Music Tech DIY Goto page Previous  1, 2, 3 ... , 27, 28, 29  Next [all]
Author [Build] Dervish - SMT Spin FV-1 DSP fx module
gbiz
Oh, and incorrect permissions on ttyACM0 would probably explain why you couldn't program the ATTiny.
technotron
And now it works! smile I remember that I set up this rule earlier when following the instructions in the 'Dervish-environment-on-Windows+Vagrant' document. But I must have screwed up somehow.

Thank you very much gbiz and ndf! ^^
gbiz
If you cut'n'paste the text & include the #'s then the command line will treat them as if they were comments in a program, & it won't do anything. I bet that's what happened.

If you want to see if that was it, run "history | grep rules" you'll get a list of every time you've run something with the text "rules" in the line.
technotron
I know that # denotes the start of a comment, so I didn't type the hashes in.

I experienced some strange problems with the vagrant environment, including not being able to see the mutable-dev-environment directory inside the VM. So it might have been something related to that.

For me, doing this project was also an eye opener on how powerful the Unix shell tools are. smile Thanks again for doing this gbiz! <3
gbiz
Oh sorry ! smile

If those issues with the vagrant image reappear, feel free to post them here. Something might be obvious as to whats wrong.

Yes, the Unix tools make handling files like the program, bank & EEPROM images so simple. That's great you've got something out of doing that, besides the ability to customise your program banks smile
Waz
Hello. I got one of these up and running. One issue I am noticing is mismatched stereo signal. It's really difficult to get a solid matched stereo signal. Is this due to the tolerances of the level pots?
gbiz
Waz wrote:
Hello. I got one of these up and running. One issue I am noticing is mismatched stereo signal. It's really difficult to get a solid matched stereo signal. Is this due to the tolerances of the level pots?


One obvious thing i have to ask, have you checked you haven't got a couple of the trimmers swapped ?. That would cause a difference in signal levels between the channels.

If it's not that, can you give more detail as to what you mean by "a solid matched stereo signal". Are you seeing this with purely dry signal as well as wet ?. Is it all programs or just a few ?.
gbiz
I've just done a re-write of the OLED code*, & i'd appreciate it if any of you who've got easy access to an AVR programmer could install this & give this a beta test for me. It's working here so hopefully you won't have any issues. It doesn't change the format of the EEPROM, so if you want to revert back to the 3.1.5 or 3.2.2 code, that should be fine. Hex file is downloadable here, & the source tarball if you want it is here. If you do test it, please let me know. Feedback will be useful. Unless i hear of major issues, I'm going to make this the default in pre-programmed ATTinys in a couple of weeks.

The new code has a basic line drawing ability, so gone is the fugly line of '=' across the screen, replaced with a seamless narrower line. The bank name list is now flicker free when you scroll down through it. Same goes for the main program screen. Bank select keeps the inverted text support from 3.2.


*I've had to do the re-write as i'm finding it difficult to source SSD1306 OLEDs. Increasingly vendors send me what are labelled as "SSD1306 (new)". These have a 20-way FFC foil connecting the controller to the carrier PCB, ("old" displays have 30-way), & i from what i have read suggests they are actually SSD1315z, not SSD1306. The new ones are supposed to be compatible, but none worked in the Dervish modules i tried here. Rather than debug the issue with the SSD1306Ascii library that Dervish has been using up to now, i decided to rewrite the OLED handling code from scratch in C (upside ... no more C++ \o/ ). The new code works fine with either display controller. I only implemented support for what Dervish actually uses, so the code is a lot smaller. Eg the Dervish display layout is hardcoded to use a 5x7 font, so support for multi-row fonts was adding a lot of unnecessary bloat. I've removed the requirement for the ATTinyCore library, something i've wanted to do for a long time. Dervish with pushbuttons doesn't need it. The new code is now 25% smaller & a much smaller memory overhead. The benefit of the latter means it now has enough free memory to implement a cache for the bank names, speeding up the bank selection screen.

(I think the issue turned out to be with how i was implementing contrast levels. The SSD1306 has contrast levels documented as 0x01 to 0xff, but I was using 0x0 to 0xff, which by luck worked fine, so i never noticed i was using an unsupported value. I suspect the 1315's have implemented a contrast value of 0x0 as blank screen, but thats hard to confirm as there's no programming manual available for it that i can find. I run all my modules with contrast set to 0x0, so all the modules i tried the 1315 in it didn't work but the 1306 worked fine).

These "(new)" displays are also slightly smaller physically. They seem to be 0.91" but vendors still sell them as 0.96". The smaller size footprint still fits, so no problem there, & the text occupies more of the glass area of the screen, so display wise, there's minimal difference in use.
Altitude909
on it.
gbiz
Altitude909 wrote:
on it.


thumbs up
secrethero303
gbiz, do you know which version was included in the kits you recently sent me? Once I finish building them, I’d be happy to try installing the new code to test too.
gbiz
secrethero303, the current attiny88_oled.hex is 3.2.2.

The easiest way to check on a running module, go to the debug screen, it shows it there, along with the amount of free memory.

Yes please, give the new code a try. thumbs up
Altitude909
gbiz wrote:
Altitude909 wrote:
on it.


thumbs up


Looks good. I like the bank name for sure, Everything seems to work as expected but the kerning on that font seems a bit tight, the letters connect to each other in most cases.

If you're having issues with sourcing the displays, you should just make your own. It's probably going to be a bit more per display but you wont have to play hide and go seek finding the right ones. Just get a hotbar attachment for your iron (or just do them one by one), its a LOT easier than it looks. I stopped hunting for OC displays a while ago. I just get the screens separate and have the boards made how I want them
gbiz
Altitude909 wrote:

Looks good. I like the bank name for sure, Everything seems to work as expected but the kerning on that font seems a bit tight, the letters connect to each other in most cases.


Thanks for checking it.

The font itself hasn't changed so it's down to how my code is positioning each character. I'll add a pixel spacing between them & see how that looks. I suspect it'll mean losing one character width on the bank select screen to provide them, but that's back to the number of characters of the previous code so it's not really losing anything. It's late here now, I'll give it a go in the morning & post the new hex up.

Quote:

If you're having issues with sourcing the displays, you should just make your own. It's probably going to be a bit more per display but you wont have to play hide and go seek finding the right ones. Just get a hotbar attachment for your iron (or just do them one by one), its a LOT easier than it looks. I stopped hunting for OC displays a while ago. I just get the screens separate and have the boards made how I want them


If i was starting from scratch again i would, but its probably not worth it now. The only issue was with these "new" displays, but now they're working i'm good (for now).
gbiz
I tried adding that extra pixel spacing. The text definitely looks better, but now, as i suspected, bank/program/control strings that are the full 20 chars lose some pixel columns at the right of the screen. So i've added some basic proportionality to the font handling (anything that already has a blank row of pixels on the right doesn't get the extra row of pixels) & that helps some.

For the program screen i currently have 4 options. See image below
1 is basically what it was previously but with the continuous line & new font code
2 includes the program & pot number & a 4 pixel version of ": ". May drop a column or two off the end of the longest 20 char strings.
3 is 2 but with a full ": ". That certainly will drop pixels off the end of the longest strings, as below.
4 is 1 but without the program number

Personally i prefer 4.

The bank select display will drop pixel columns with the longest strings. I'm not too fussed about that.

If you want to check out each display option attiny code, i've bundled them all into this tarball. I've deleted the previous attiny hex & source until i get this sorted, then i'll re-upload it.

pld
Nice. I'll try and give it a test when I have a minute.

Although I'll mumble a bit under my breath a bit because of
gbiz wrote:
(upside ... no more C++ \o/ )

but will let it slide because it's an attiny (and better good C than bad C++) smile

It's maybe a bit too small to be useful, but maybe icons instead of the pot numbers would work?
Altitude909
4 for sure. Much cleaner
gbiz
pld wrote:
Nice. I'll try and give it a test when I have a minute.

thanks. (If you want the source let me know & i'll post it back up).

Quote:

Although I'll mumble a bit under my breath a bit because of
gbiz wrote:
(upside ... no more C++ \o/ )

but will let it slide because it's an attiny (and better good C than bad C++) smile


haha. What if it's it's bad C replacing good C++ ?

I never really liked the idea of mixing the two. Now at least all of it is in my hacky C smile

Quote:

It's maybe a bit too small to be useful, but maybe icons instead of the pot numbers would work?


I did think about doing something like that, but an icon would have to be 10x8 pixels max. As you say probably a bit too small.
pld
It definitely works smile

gbiz wrote:
haha. What if it's it's bad C replacing good C++ ?

I never really liked the idea of mixing the two. Now at least all of it is in my hacky C smile

Isn't all C hacky? w00t
(in case it's not obvious -- I kid, SCNR, no flame on please).

Quote:
I did think about doing something like that, but an icon would have to be 10x8 pixels max. As you say probably a bit too small.

Yeah, it's pretty tiny. Someone with a better eye for design than me might have an idea, but mainly I deal in programmer art smile

Maybe 5) without a separator? Admittedly the numbers aren't really providing too much additional information.

(this isn't the updated keming).

Spontaneously one might display the bank/program number for a short interval on change and then hide it, but that could easily be too busy/annoying.
gbiz
pld wrote:
It definitely works smile


thumbs up beer!

pld wrote:

Isn't all C hacky? w00t
(in case it's not obvious -- I kid, SCNR, no flame on please).


You're probably safe saying that here on Muffs sdiy wink

Quote:

Quote:
I did think about doing something like that, but an icon would have to be 10x8 pixels max. As you say probably a bit too small.

Yeah, it's pretty tiny. Someone with a better eye for design than me might have an idea, but mainly I deal in programmer art smile


hahahahahaha

Quote:

Maybe 5) without a separator? Admittedly the numbers aren't really providing too much additional information.


That still means some of the control descriptions that use the full 20 chars could lose a few pixel columns on the RHS. I think the full description without the number looks cleaner.

Quote:

Spontaneously one might display the bank/program number for a short interval on change and then hide it, but that could easily be too busy/annoying.


That would mean after the delay, shifting all the text over to the position the numbers were occupying. I agree, it would look a bit busy, and would probably annoy me after a while.

The SSD1306b has support for sliding text, so if everyone had displays using that controller it'd be possible to do some eye candy & slide the text into place & have the number pixels drop off the LHS. The 1306b doc states it also supports gradually fading the screen to dark, which i had hoped to use when the screensaver kicks in, but I couldn't get that to work with the controllers i have here unfortunately. The equivalent 1306 doc i have doesn't mention screen fading support, it seems to support just the minimal set of essential commands, so i suspect its a 1306b feature only & my displays here are vanilla 1306 or 1315z. Shame. I tried implementing fade with "while (contrast) { setContrast(); delay(); contrast--; }" but decided against using it. There's a marked jump between contrast of 1 & screen off, not the nice fade out i was hoping for.


I've just updated the zipfile & ftp tree so it's all there now. This code is here. The attiny88_dervish.hex is in kwikfiles as usual. Option 4 is currently the default in the code & the hex files. But if anyone wants to hack with other options, i've left that code there for now & a #define DISPOPTION in inc.h to change it (use 1, 2, 3 or 4 corresponding to the image above), then recompile. The code layout is in display.c, just look for the #if DISPOPTION lines. At least compilation is much easier now as it only needs the standard avr-gcc/avr-libc.
The tarball mentioned previously with those 4 precompiled hex files is still available.
secrethero303
I think I prefer option 4 as well, the numbers don’t add too much and it looks much cleaner.
kogz23
Uploaded the new Attiny code and the OLED looks great.
I am having some probably unrelated issues though. One issue is that when I change program the effect only changes every 2 pushes. i.e Push down button: The display shows a change, but the effect stays the same. Push again: The display changes and so does the effect.I hope that makes sense, terrible description I know!
The other problem I am having is getting clock sync to work. This could be related to the above issue. It is creating some cool, but very unpredictable results.
Thanks!
gbiz
kogz23 wrote:
Uploaded the new Attiny code and the OLED looks great.
I am having some probably unrelated issues though. One issue is that when I change program the effect only changes every 2 pushes. i.e Push down button: The display shows a change, but the effect stays the same. Push again: The display changes and so does the effect.I hope that makes sense, terrible description I know!


It's working for me & nobody else has reported it. I didn't make any changes to the program select code, (especially not the part that generates the program select lines for the FV-1), so there shouldn't be any issues with it. Did it work before you updated the code ?. If you revert it back to one of the older attiny code releases does it work again ?. (hex files for 3.1.5 & 3.2.2-pb are in the online kwikfiles directory here) If one of those older versions works, let me know. Whilst you're trying different code versions, just so i know you're running the latest (you didn't say which version of the new oled code you've installed), try the attiny88_dervish.hex in that same kwikfiles directory. (The debug screen reports it as version 3.3.3).

Whilst i'm not going to rule out an issue with the new code, as it's working for others, TBH it sounds more like you have an issue with the select 0 (SW0) line from the attiny to the FV-1. This should toggle between 0V & 3V for alternate program selections. It sounds like yours is stuck at one voltage level. The first place to check that signal is on the ATTiny pin 24 (the bottom pin on the left hand row of pins, by the clip led, so relatively easy to access once you have the panel off). If that's toggling between 0 & 3V on each button press, check pin 4 on the 8-way header between the boards (pin 4 is the one to the left of the "J3" text thats above the I2C header) & pin 16 on the FV-1.

Quote:

The other problem I am having is getting clock sync to work. This could be related to the above issue. It is creating some cool, but very unpredictable results.


The ATTiny doesn't have any involvement with the programs themselves, so thats definitely unrelated to the code update smile
You don't what signal you're using with it. There's three things that can impact getting it working
1) ideally use as close to a 50:50 duty cycle on the clock waveform as you can. A short pulse will get filtered out by the FV-1 & probably won't work. Low & high levels have to be stable for a period of time before they're counted as valid to prevent noise being counted as a clock signal. (Someone reported issues with a Pamelas with a 5% gate pulse. Configuring the output to a wider pulse on Pamela fixed that).
2) Use the pot to set an offset voltage, so the clock signal will shift between detectable 0 & 1 as far as the cv input on the fv-1 is concerned. What offset you need to apply depends on the voltage level of the clock you're using. With a 0-10V clock, the pot can be almost totally CCW. With a 0-5V clock, i find the control at about a third (roughly 10am) works. You'll know when it's the right level as you'll hear the delay sync.
3) the clock pulse period has to be less than the maximum delay time for the effect. Most of my clocksync programs now have the maximum clock period as part of that control's label text.

Clock sync can be tricky to get running because of the severe signal filtering on the CV inputs internally in the FV-1 itself. (If you present a 50:50 square wave to the CV, the FV-1 CV inputs will see it as a rounded triangle). Theres no easy way to work around that. You need to have a sufficiently wide clock pulse & use an offset that gives low & high signals for sufficient time for the program to sync.
The clocksync delay programs start at a default period, dependent on what the maximum delay time for that program is. They'll remain at that time until it can lock onto a valid clock pulse. If it subsequently loses sync it'll continue with the last valid period. It'll lose sync if the signal is too weak so it doesn't swing between detectable levels for long enough, or the period between pulses exceeds the maximum delay time. if you're getting wired syncing issues it might be that the level isn't quite right. Try adjusting the pot voltage or the width of the clock pulse.

For the single tap delay programs the maximum delay time is 1sec, for the 2 tap delays (ie the ping pongs) it's 500msec, & for the 4 tap delays (stereo ping pong) it's 250msec. I can't remember what the hardcoded default delay times are - iirc the single tap one is 300msec. It's in the code.

(I really should put this into a howto ! smile ).
kogz23
Thanks for the suggestions/insights.
The version I had was the 3.3.3 hex. When flashing it it did mention something about detecting a new fuse "keep or use new value" or something to that effect. Responding "yes" halted the process, so i answered "no" and the flashing seemed to go fine. I am not sure if this could have caused a problem.
So I tried earlier versions and I have the same situation with the only every other program loading. So it must be a hardware issue eek!
I will check the area you suggested and report back.

Concerning the clock, it sounds like user error. I am using a Midibox Seq4 to provide clock. The clock width is 1ms, but is adjustable. I tried various PPQN settings. 16PPQN seemed to have the most effect, though it was pretty wild!
gbiz
kogz23 wrote:
Thanks for the suggestions/insights.
The version I had was the 3.3.3 hex. When flashing it it did mention something about detecting a new fuse "keep or use new value" or something to that effect. Responding "yes" halted the process, so i answered "no" and the flashing seemed to go fine. I am not sure if this could have caused a problem.
So I tried earlier versions and I have the same situation with the only every other program loading. So it must be a hardware issue eek!
I will check the area you suggested and report back.


No, the fuses thing is not an issue. There's some unused fuses in the attiny88. I don't set them, so i play it safe & leave them at "1" but some read back as "0" so the verify complains.

Those program select lines go directly from the attiny to the fv-1, so it can only be the soldering on the attiny, the fv-1 or the header pins between the two boards. There's no other components involved.

Quote:

Concerning the clock, it sounds like user error. I am using a Midibox Seq4 to provide clock. The clock width is 1ms, but is adjustable. I tried various PPQN settings. 16PPQN seemed to have the most effect, though it was pretty wild!


It's not user error. Blame it on the lack of documentation of what clock signal the program is expecting wink

I suspect that's still too fast, which would explain why it sounds wild, though it's probably fine for a clocksync'd flanger smile You only need one pulse per delay period, so if you can, try 1ppqn, or even lower, eg 1 pulse per bar.

Just as a test to getting it working, try an alternate clock source, eg the square wave from an LFO. Try varying the level of the control pot & the frequency of the LFO to see how the delay reacts to changes with those.
MUFF WIGGLER Forum Index -> Music Tech DIY Goto page Previous  1, 2, 3 ... , 27, 28, 29  Next [all]
Page 28 of 29
Powered by phpBB © phpBB Group