Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - jarilo

Pages: [1] 2
PreenFM2 / Re: Thoughts about operator tuning
« on: September 08, 2017, 11:38:29 AM »
This is great news, I'll check it out as soon as I can!

Just took a glimpse at the changes, and I am very happy to have a reference for future fiddling with UI code (hope I find some time for that), thanks for that!

PreenFM2 / Re: Yellow OLED : high frequency solution
« on: May 15, 2016, 03:40:45 PM »
Tested in rehearsal studio situation (finally), works perfectly, no high-pitched noise here. I've turned the mixer volume as high as it goes, to the point where I hear (relatively) loud white noise, and there is no ~15kHz peak.

I haven't yet come to measuring it with real tools, but I am perfectly satisfied with this, as it can be used in live situation, as far as me and my people are concerned.

Thanks again,

PreenFM2 / Re: Yellow OLED : high frequency solution
« on: April 05, 2016, 02:26:05 AM »
Yes, I did cut the pin from oled. I forgot to say most important thing, that I did all modifications :D

I was comparing (by naked ear) first only with shield, and after that shield+resistor+modified oled pcb. It was silly to compare it, because it is impossible for me to determine volume of sound of such high frequency by ear...
What I wanted to say is that I was pleased with results even when using only shield. (but did all of the modifications nonetheless)

Anyway, after playing with it for a few hours, I can confirm that I can no longer hear high pitched sine through my speakers, but I can hear it from preenfm2 box (I have moved box 3 meters away from speakers to be sure).
This is what clement mentioned in other thread, probably coil oscillating.

As high-pitched noise is practically eliminated in signal, I am no longer motivated to try a steel shield. :)


PreenFM2 / Re: Yellow OLED : high frequency solution
« on: April 04, 2016, 11:15:18 PM »
Done and done, 64 layers of alu foil, wrapped in antistatic bag twice and then sticky tape (not sure if antistatic bag can damage something, just to be sure).

High pitch noise is drastically reduced just by adding this shield. (sadly, I didn't try to make a shield as proposed by clément, I suppose I was too lazy to cut and solder perfboards :) )

I didn't hear any difference with or without 22 ohm resistor, but I was only using my ears for testing, as I don't have oscilloscope... After soldering, I used soundcard oscilloscope (didn't come to my mind earlier), and peak is much lower with shield.

I am thinking about making (some day) shield out of thin steel sheet, like on RF tuners, this could maybe lower magnetic noise...

Thanks very much,

PreenFM2 / Re: Thoughts about operator tuning
« on: March 25, 2016, 04:09:28 PM »
That would be fun!

Or Hz based detune per timbre, for flanger-like effect when using same patch on different instrument slots.

I might actually try this, when I make me some more free time...

Computation-wise I suppose it wouldn't be to hard on cpu, just adding simple increment value (related to detune value) to phase increment :)
I haven't yet touched anything in preenfm2's UI code, so that might get a bit tricky there, I don't know...

PreenFM2 / Re: Voice allocation / keyboard management
« on: March 22, 2016, 04:46:04 PM »
And more than a month if we fed it only noteon messages as fast as serial midi allows, if I've calculated it right.
Yes, acceptable to say the least! :)

And it's easy on cpu operations, compared to what monstrosity of a logic I had in mind!

I just wanted to be completely sure I understood this.
Thanks for the reply!

All the best,

PreenFM2 / Re: Voice allocation / keyboard management
« on: March 19, 2016, 11:41:24 PM »

I have more questions for you, Xavier :)

I am still looking into this "voiceIndex" logic - I think I understand it completely, just want to be sure of these few things:
- I don't see voiceIndex being initialized to any particular value anywhere in code, I suppose it mostly doesn't matter, or is it implicitly initialized to 0?
- As I understand, once in a while voiceIndex reaches maximum 32bit value, and wraps around (very rarely, obviously, once in 4 billion noteon events :) ). Does this mean that during this wrapping, some of the allocated voices will be incorrectly tagged as older, even though they aren't?
For instance we have voiceIndex values MAX-1, MAX, 0 and 1 - logic is such that smallest value is regarded as oldest, but in this example this is not the case. Did I understand this correctly?

Sorry for bugging you with all these questions, but I really enjoy all of this. :) As a side note, I started prototyping my own hobby synth on linux pc, and as one of first things I want to solve voice allocation.


Thank you very much for answer!

I saw you mentioning magnets, so I asked :)

I'll shield it as you did, and try it at least at the rehearsal studio, to see people's reactions :D

All the best,

Hi everyone,

sorry for digging this thread from the past, but I also have this high pitched peak problem with yellow oled.

I would like to ask you clément what kind of magnet did you use, and how much difference did adding magnet to cage make?
I have some broken fridge magnets floating around, I suppose they could be used... Do I just put them there and tape/solder them onto the cage?

I'll experiment a bit over the weekend, but I guess it is better to be prepared with other peoples experiences if possible :)


PreenFM2 / Re: Voice allocation / keyboard management
« on: March 15, 2016, 03:02:04 AM »

here's the new update.

Last edit in first post explains what this update is all about. I could maybe organize this a little better, to avoid flooding this thread with redundant info...

All the best,

PreenFM2 / Issue when gliding fixed frequency operator
« on: March 05, 2016, 01:13:14 PM »

When you glide from one note to another (and have fixed operator in current timbre), fixed operator frequency also glides.

Problem is that formFrequency and nextFrequency aren't the same most of the time, so I just forced them to be in Osc::glideToNote()
If incidentally you can't hear gliding of the fixed operator (because frequencies are equal), just try changing its frequency in appropriate operator tab.

Here's the fix in the patch.

All the best,

PreenFM2 / Re: Voice allocation / keyboard management
« on: February 22, 2016, 11:17:18 PM »
I've finally managed to find some spare time and work a bit on this.

I've attached patch file and compiled firmware so anyone could test it out. Long story short - it works for monophonic mode (glide or no glide), but acts weird in polyphony. It's probably not a big problem in polyphonic mode, as playing style is quite different from monophonic, but I will continue working on this for the sake of completeness :)


PreenFM2 / Re: Voice allocation / keyboard management
« on: February 04, 2016, 07:57:36 PM »
Hi Xavier,
thanks for clearing everything up, I think I now understand it fully, and I see most of the hard work is already done here.
It only leaves me with adding note stack, and automatic note triggering logic on noteOff (if voice is freed in process). And, of course, having in mind voice index.

I will put updates here as I progress (and when I am stuck :D )

Thanks very much,

PreenFM2 / Voice allocation / keyboard management
« on: February 04, 2016, 12:02:19 AM »
I am trying to modify voice allocation in preenfm2, and I'm currently studying the code.
I want to make it more playable by keyboard - for instance, in current implementation, when monophonic mode is chosen, when I press and hold 3 keys in some order, and then I lift first and last, second one isn't triggered.
What I want to do is add stack which will hold all pressed keys in order they are pressed, and as a player depresses some key, it is removed from stack and replaced by the one before it.
Few top keys on stack (depending on the polyphony) will activate voices, and as they are released, the ones before them will jump into freed voice, and trigger a note. (I don't know if I explained it well)

I have a basic logic figured out, and implemented a very simple test console application (it will surely need some work to be adapted to preenfm2).

Now I want to understand as much as possible logic around current implementation, so I could do it with as smoothly as possible.

For now, I have few questions about some specific details:
I understand (maybe incorrectly) that first for loop in preenNoteOn iterates through all voices reserved for this timbre to check if they are free to use. I think I understand remaining logic, as well, but I don't quite understand what "index" of a voice is used for. I suppose it has something to do with the order of voice allocation, but it may not be the case...

Anyway, thank you Xavier for making this very great synth, and above all for making it open source, so people can see how things are done in real world. I am really inspired to make my own, if I find enough free time, and after I get my hands dirty enough with preen.

Attached first working changes - patch file and two firmware variants (optimized and non-optimized).
In monophonic mode it works perfectly, as far as I have tested it. In polyphony it doesn't work as I intended it to, so I will investigate it further.
I am uploading it here as it is for anyone that want's to check it out, but I will continue working on this, depending on my free time.

Anyway, changes are miniscule as note_stack is already there and used by arpeggiator (I've added separate instance for manual performance), and I've added one method to it that I needed, and few small changes in other places...

another edit (mar 15, 2016):
New upload. I've experimented with polyphony and note stack, and when implemented correctly, it feels strange - imagine 4x polyphony, you hold 3 note chord with one hand, and than press another 3 note chord with another hand, than release second chord. When released, first chord gets triggered, and most of the time it doesn't sound like something you would have wanted to play on keys.
So I've decided to leave keyboard behavior in polyphony as it is originally implemented by Xavier, it's probably the best way to do it in poly. In this latest patch, stacked legato is active only when glide parameter is greater than 0.

I could (and will, as I find some more time) clean this patch a bit, as I think nextGlidingNote might be redundant after this change... And probably few other things.

Attached are both prepared firmware (including compressor/distortion/fuzz effect) and patch with newest changes. Old versions are removed, as this new version is like totally better than the older one.

PreenFM2 / Re: Compressor/fuzz effect
« on: February 02, 2016, 07:58:53 PM »
Thanks for the tip!

Firmware is attached to the first post, everyone is welcome to try it out and please share your thoughts on it.


Pages: [1] 2