SynthMakerDigitalWhiteByte ·
I think it is impossible to achieve, but the thing I do not understand is why the count of ticker100 go slower. 😮
Edit: Uploaded new version.
Tiker 1000 Real or Illusion?
From the original SynthMaker forum (2004–2014), with its members’ names and dates.
malc ·
All the timer components use Windows timers. They are only accurate to about 10ms and can sometimes be even worse than that.
The reason they are inaccurate is because they use the normal Windows event system. Callback events are posted on the message queue alongside other Windows events like mouse, keyboard and commands. The timer events have a very low priority so during busy periods, where there are many other messages in the queue, timer messages can get delayed.
The timer components in SynthMaker are not intended for tasks where accuracy is required. They were originally introduced to provide a way of performing simple animation and for that purpose the inaccuracies are acceptable.
Hope this helps! 🙂
DigitalWhiteByte ·
Thanks Malc, in fact we have already addressed this issue at length, but my hope is in the seriousness of the updates for this application, to make sure in future the best existing solution for generating high-quality audio software, the first step I think it is just that.
You are a great developer, and the community is excellent, many people believe that this software will become a tool of professional development.
😀
mcfadden555 ·
we really need this tiker (1000 or higher) 🙁
infuzion ·
mcfadden555 wrote: we really need this ticker (1000 or higher) 🙁
"Need"? For what please?
mcfadden555 ·
We need it , to have the option, to trigger faster (Mono to Float) ..... I need a faster tick then 100 to finish one of my projects (My dream would be a tick44100, but 1000 ticks is also good -it would be an enhancement to 100 ticks......
I'm not the only one who need a faster Tiker.... there are many posts of people who want it....
I think:
faster Ticks = New Options for development
if you have the choice between a Ferarri and an Audi,
what car would you take ???
I want a faster Tiker 🙂 !
musical greetings,
monx ·
Illusion
mcfadden555 ·
why ?
oddson ·
Not necessarily a faster ticker (although it would likely become possible as well) but a means of sending triggers from the code module and having them actioned in a much more precise time-frame than is currently possible (i.e. relying on sampling a stream output with a ticker and an M2F) even if it's still not sample accurate.
The biggest area this would open (IMHO) is note event processing as currently the timing inaccuracies are far too great for musical applications.
Or full sample-rate accuracy for all events would be good. 😉
Tzarls ·
Redraw Limiter not quite working
That would do it. 🙂
infuzion ·
mcfadden555 wrote: We need it , to have the option, to trigger faster (Mono to Float) ..... I need a faster tick then 100 to finish one of my projects (My dream would be a tick44100, but 1000 ticks is also good -it would be an enhancement to 100 ticks.
Well if you need to process at sample rate, then use stream Code at sample rate.
Then only place where more accuracy is needed IMHO is for MIDI. And SMX/SM2.0 is supposed to do that.
mcfadden555 ·
Thanks infuzion, Thanks oddson,
Many thanks for your efforts and your quick reply.
Do you mean : stream the mono in (with 44100 hz) to float ???
it sounds to me like a ray of hope. 🙂 do you have an example OSM/ or Picture or do you know somthing like that in the Forum ???
musical greetings,
rl ·
Why would you want a float with changes at samplerate? Tell us, what you want to accomplish, and we might find a solution.
mcfadden555 ·
I hope you do not understand me wrong. I do not want to talk about my idea and for what I need it. because my idea should remain my. I hope I have said clearly enough what I want.
you said it:
I want a float with changes at samplerate (mono to float in samplerate)
I just want to know, is it possible ???
trogluddite ·
A float changing at sample rate is a stream. The green floats could never run at anything like that speed because of the overhead of passing the triggers through the schematic (to calculate which calculations need calculating - if that makes sense?) - your CPU would melt down! Code is the only way to go - a code module is executed at sample rate by definition. The limitations this imposes on MIDI and the GUI are well known, but unavoidable at the moment - the division between sample rate streams and 'run on demand' green/GUI is part of what makes SM relatively user (and CPU) friendly - IMHO, the way this opens up VST design to amateurs is a key point of SM. To have the kind of power/flexibility available to people like Native Instruments, there's nothing for it but to program in C++/ASM.
The Luddite.
mcfadden555 ·
Thanks,
I'll try a to write a code to solve my problem. Unfortunately, it can not work all at once. I work with synthmaker're only one year. Therefore, there will be a challenge for me.
musical greetings
brokebust ·
+1000000 to this post.
Please please please fix green timing - or explain to me what the solution is that I'm missing. Everything i want to do requires it - I don't build "normal" synths - I'm interested in timing effects and controllers.
Example: A code block outputs a stream, OS, which is a constant value between 0 and X, and that output stream value OS changes when an input signal, IS, goes above a threshold. When that OS value changes, I need to generate a MIDI message. In a nutshell: when an input signal goes above a certain level a midi note is triggered.
AFAIK the only way I can detect a change in OS and send that to a MIDI message generator is via the ticker to get periodic values of OS and check them against the previous value. The timing for this is a--p--a--l--l--i--n--g, despite the fact I can see that the code output is changing with near-perfect accuracy.
It's like you have a fortune in a bank account but when you withdraw anything it's immediately devalued: ultimately frustrating. This is a massive and fundamental problem for me.
I have actually given up using SM until this problem is solved - I only come to the forum periodically to check if it has. I saw a post a long time ago saying it was a key priority - but still no release - is this intended be solved or not? If it will not be solved please tell me so I can abandon ship in enough time to swim over to HMS MaxMSP where the ticker works even if the app is not integrated into my host! 😉
MegaHurtz ·
What you can do here for a 2%, msp will do at 20%, reaktor at 30%. I would reccomend not to abbandon ship for the cost of a steeper learning curve. Every solution to a problem here is a real one, and as soon as you get the grips. It will sing for you in paying real dividence. instead of many build hours that will not be able to hit the market. The flaws in green timing are there in msp. They are the same. It`s the streams that are a real PITA in msp.
MegaHurtz ·
trogluddite wrote: A float changing at sample rate is a stream. The green floats could never run at anything like that speed because of the overhead of passing the triggers through the schematic (to calculate which calculations need calculating - if that makes sense?) - your CPU would melt down! Code is the only way to go - a code module is executed at sample rate by definition. The limitations this imposes on MIDI and the GUI are well known, but unavoidable at the moment - the division between sample rate streams and 'run on demand' green/GUI is part of what makes SM relatively user (and CPU) friendly - IMHO, the way this opens up VST design to amateurs is a key point of SM. To have the kind of power/flexibility available to people like Native Instruments, there's nothing for it but to program in C++/ASM.
The Luddite.
After reading back a little, there are no limitations on midi and not on gui. Midi was already slow when it came in. you are`nt going to get any faster. If it was based on a host the difference would be uncomprehenceable. Same goes for the gui.. Unless you have a supermind that can detect changes in image above 24fps. Wich we dont have. The slower ticker will suffice. So a ticker 100 will be redundant by 300%.
brokebust ·
Thanks for your inspirational words but what I really want is a technical solution - or at least hope of one coming along 😉
I want to be able to synch things accurately - to an accuracy that I know is possible. When a stream changes I want to send out a MIDI note at that point, with no greater audible latency than if I had hit a key at that same point - which is hardly asking much I feel.
I can see no fundamental mechanism to achieve this or other simple timing goals - like firing messages in time with the host's BPM. Everything comes back to taking the stream (e.g. BPM) and then sampling out floats at massive intervals (with the ticker) so the synch is totally lost.
MegaHurtz ·
you can have a subframe of signal timing with a controlrate midimessage. Pure midi is not that slow, see your keyboards and stuff they still use the outdated midi protocol from way back. If you would do this via a ticker 44100, it will still be off track. For technical reasons described by malc in this post. So a signal "heartbeat" is the way to go.
brokebust ·
When a stream changes I want to send out a MIDI note at that point, with no greater audible latency than if I had hit a key at that same point - which is hardly asking much I feel.
So a signal "heartbeat" is the way to go.
That could not work, because the signal could change at a point that was not on a "beat". If you need me to explain the issue again in more detail I can.
Either way, still no solution! 😠
MichaelBenjamin ·
a stable tickersystem to produce and merge stream, midi & control data would be very nice.
MegaHurtz ·
brokebust wrote: When a stream changes I want to send out a MIDI note at that point, with no greater audible latency than if I had hit a key at that same point - which is hardly asking much I feel.
So a signal "heartbeat" is the way to go.
That could not work, because the signal could change at a point that was not on a "beat". If you need me to explain the issue again in more detail I can.
Either way, still no solution! 😠
Read harder 🙂.. The signal will never change on beat.. It`s always limitted to the midi protocol for compatibily with midi. And it`s faster than you can grasp.
trogluddite ·
MegaHurtz wrote: The signal will never change on beat..
Always some latency yes, and MIDI is reasonably quick (not quick enough for me - I play drums, and the flamming on my MIDI percussion kit drives me crazy). However, that doesn't get around the fact that tick 100 is a whole order of magnitude slower than MIDI. 10ms between ticks is definitely enough to give audible latency jitter. Depending where the ticks come relative to the musical timing, a note may be delayed by almost nothing, or by up to 10ms - it is the variation (jitter) in latency that makes timing sound sloppy. In contrast, a fixed delay of almost any length could just be compensated for. For a VST instrument no problem, the trigger occurs at the moment the message is received - but if your plugin uses tickers to trigger notes (i.e. step sequencers, MIDI delays etc.) then it does make a difference, especially for percussion sounds. I remember reading some research years back that found that timing differences of this order in the drumming affected people's perception of 'swing' in jazz recordings, for example.
MichaelBenjamin ·
on the other side its quite astonishing that the windows ticker got such a shitty timing. if one builds an operating system i would assume that stable clocking and ticking would be one of the main features to provide. i can imagine with all that multitasking this could be hard, but that the devs didnt even implement also some time critical mode for realtime applications to rely on even with tradeoffs in multitasking is beyond me.
oddson ·
10 MS might not be good enough... but the 15-to-god-only-knows reality is even worse. It's the low priority that's the game killer. SynthMaker will not be suitable for any music event system until that's done. If it doesn't quite get to sample rate that may or may not prevent some applications but it's completely a no-go with the current system.
And now that's the final word on the issue and we'll all agree never to speak of it again even after it's fixed. 😉
trogluddite ·
oddson wrote: And now that's the final word on the issue and we'll all agree never to speak of it again even after it's fixed.
Yes, time to move on to pastures new... "Ticker 25 Real or Illusion?", anybody? 😉
rl ·
oddson wrote: And now that's the final word on the issue and we'll all agree never to speak of it again even after it's fixed. 😉
but will it ever be fixed?
matti ·
MegaHurtz wrote: Unless you have a supermind that can detect changes in image above 24fps. Wich we dont have. The slower ticker will suffice.
Wha-wha-wha-Whaaaat!? Human eye can detect changes at approximately 70 Hz (or fps if you like). Have you ever watched old TV's that have a refresh rate of 50 Hz. That flickering starts to hurt your brain. Compare it to one that goes 100 Hz. You should notice a huge difference. Same as playing a game at 24 fps or at 60 or 100 fps.
Andrew J ·
Or is that flicker just aliasing below 24Hz - and increasing the refresh rate just moves the alias above 24Hz? I don't know really - just speculating without bothering to research...
NothanUmber ·
infuzion wrote: Then only place where more accuracy is needed IMHO is for MIDI. And SMX/SM2.0 is supposed to do that.
Ah, nice a thread about my most beloved SM feature request from four years ago 🙂 Is there light somewhere on the horizon regarding SM2 and MIDI? I still have some MIDI effects in the drawer that I could finish if the MIDI timers would be more precise. Happy SMing, nice to see some old names, hat off to your staying power!
Greetings from a still (from time to time) lurking NothanUmber
MegaHurtz ·
Andrew J wrote: Or is that flicker just aliasing below 24Hz - and increasing the refresh rate just moves the alias above 24Hz? I don't know really - just speculating without bothering to research...
In that 1/200th of a second the whole screen is built from lines, so your screen is moving.
JIftw ·
MegaHurtz wrote: Unless you have a supermind that can detect changes in image above 24fps. Which we dont have.
Offtopic: Must have been a typo... otherwise you may want to multiply that number by 10. 24 fps is only an approximate framerate at which you begin to interpret movement from a succession of still images.
MegaHurtz ·
it`s actually 2 frames over 22hz wich is not completely coincedental the fundzmental frequency of our ears. That slow are we.
trogluddite ·
Yup, the output from the flashgun on a camera is typically 1ms long - but it certainly isn't invisible. 24/25fps came about because it worked well for the vast majority of cinema audiences and is easy to synchronise using the frequency of the mains electricity supply. Faster rates would look smoother, but would have increased the length of film needed, and risked tearing the sprocket holes out of the celluloid.
If 24fps were the max percievable frame rate, I wouldn't find the flickering of flourescent tubes at 50Hz anything like as irritating!!
MegaHurtz ·
trogluddite wrote: Yup, the output from the flashgun on a camera is typically 1ms long - but it certainly isn't invisible. irritating!!
That`s becouse the presence of it being there was noticed in your 1/23th period 😉
I guess becouse the period of magnetic energy was yust right for your eyes to get excited. based on how light seems to excite eye cells, and the charge produced has a capacitator like dropoff... it`s sticky to the brain. Also the period and layer of perception seems to vary a bit based on you preference. Adrenaline seems to heat it up quite nicely. But it`s all quite selective and grouping in both hearing and vision.
trogluddite ·
Persistence of vision certainly plays a part - the time it takes for the retina to 'discharge' the flood of photons. You're spot on with the 'layer of perception' - bit like the brain also has streams and 'green' circuits (and plenty of latency!).
In terms of musical timing, or Haas delays between the ears, there's no doubt that I can perceive timing differences of the order of a few milliseconds - I can hear the flamming and process the directional information (or witness the flickering lights). The conscious mind would be swamped trying to process all that at 'sample rate', yet somehow the 'sub-ciruits' processing the senses can pass forward information about events that happen on a much smaller timescale - so I don't see the individual pulses of light, it more like a flag gets polled somewhere that says 'there's flickering going on, so you must now get annoyed'.
The weird 'forward masking' effect that gets used in mp3 encoding is my favourite example. A sufficiently loud sudden sound (say a kick drum) actually stops you from hearing the music for several seconds before the loud sound - so you can just delete that bit from the mp3 and no-one notices - the brain just says 'this was the most important thing to happen within this sub-frame' and discards the rest as not so relevant - but somwehere or other in the brain there's some damn quick processing going on deciding what to report to the conscious bit.
MegaHurtz ·
Yea it`s all based on resonance, so the resonant frequency is not the frequency of perception. It`s the perception itself that shows glitches based on the used synchronisation rates. This becouse preceived image is distorted. But not our brains our brais are hardwired to beleive what we see is smooth.
MegaHurtz ·
The weird 'forward masking' effect that gets used in mp3 encoding is my favourite example. A sufficiently loud sudden sound (say a kick drum) actually stops you from hearing the music for several seconds before the loud sound - so you can just delete that bit from the mp3 and no-one notices - the brain just says 'this was the most important thing to happen within this sub-frame' and discards the rest as not so relevant - but somwehere or other in the brain there's some damn quick processing going on deciding what to report to the conscious bit.
psychoakousticly minimised fft`s for transport 🙂
trogluddite ·
Good analogy - would make an excellent title for a new Brian Eno album too! 😉 The 'Psycho...' part is just what so much of the technical debates can miss - getting the listener to perceive/feel something - not in terms of 'ooh, the timing's good on this' or 'those high frequencies are really clear' - but in terms of 'this makes me feel happy/sad/thoughtful/excited etc etc" Knowing about the frequencies and timing and dB and harmonic ditortion and Hass effect and...and...etc.... is just a tool to help understand the magical tricks that you can play on the listener's brain to enhance those perceptions. e.g. More reverb + LP filter + Slight time delay = Far away sound - or - Little bit of swing + Muted down beats = A more 'Relaxed' feeling. To bring the thread back round to Tickers (clever eh?) - it's not so much the 'latency' or even the lack of resolution in the ticks that is the biggest problem - it is the randomness that will always defeat any kind of work-around - the interval before the next tick is too unpredictable for the conscience to ever adjust to and then filter out. Predictable+Safe, Unpredictable=Dangerous - our minds are just wired to listen out for the unexpected, and get edgy the less certain we are of the future.
P.S. Ignore anything I post at 3.20am on a Saturday morning, I am almost certainly very drunk (again). 😈
MegaHurtz ·
cheers m8
dutchound ·
I see that this thread is over two years old...
No advance on the wonky ticker? i have been using synthmaker for one day now and the first think i have noticed is that the ticker is too slow, 100 is audible when converted to pitch glissando etc.
and also it is not synchronised with the actual speed of the computer...
surely, using the X86 compatible module available in synthmaker someone has made a ticker that is faster and maybe more accurate?
any news of progress please?
trogluddite ·
No progress at all... See my answer to your other post HERE
Wrote something here? To have a post removed or your name hidden, write to [email protected].