existing in threads outside of FB which doesn't crash when shit goes bad
Does HALAC use any predictions similar to TAK? Including advanced multi-channel correlation?I don't know exactly how TAK works, I only have some preliminary knowledge about FLAC and SLAC. I want to proceed as much as possible without being bound and influenced by certain things. This way I can be more free.
If I find recent papers about better predictions causing better compression ratios I gonna write another lossless audio codec
$font(Yu Gothic UI,16,400,0,0,0)
[%title%$crlf()]
$font(Yu Gothic UI,14,600,2,1,0)$rgb(220,40,0)
%artist%$font()[ $font(Twemoji Mozilla,16)$country_flag(%country%)$crlf()]
$rgb()
$font(Yu Gothic UI,14,400,0,0,0)
[%album% '('%date%')']$crlf()
$font(Yu Gothic UI,12,400,0,0,0)
[%codec%][ %__bitrate%kbps][ %codec_profile%][ %__tool%][ %__tagtype%]$crlf()
[%output_device%]$crlf()
[DSP: %track_flexdsp%]
? That's running outside foobar, as you are showing. Yep xdQuoteObviously doing so will cost memory, but you're also overlooking webview existing in threads outside of FB which doesn't crash when shit goes bad. I've already tried things in x86 FB that have run webview threads >6GB (which I could always kill manually if necessary) and FB was still running fine.Obviously if you are running things outside foobar, you can do whatever you want. I don't get the point of that... if you are saying this component can run 6GB data in foobar x32, that's another thing. It can't.
All the things that can't be done, right?
Because no method currently exposed will do that. All current methods work on single paths.QuoteObviously doing so will cost memory, but you're also overlooking webview existing in threads outside of FB which doesn't crash when shit goes bad. I've already tried things in x86 FB that have run webview threads >6GB (which I could always kill manually if necessary) and FB was still running fine.Obviously if you are running things outside foobar, you can do whatever you want. I don't get the point of that... if you are saying this component can run 6GB data in foobar x32, that's another thing. It can't.
Obviously doing so will cost memory, but you're also overlooking webview existing in threads outside of FB which doesn't crash when shit goes bad. I've already tried things in x86 FB that have run webview threads >6GB (which I could always kill manually if necessary) and FB was still running fine.Obviously if you are running things outside foobar, you can do whatever you want. I don't get the point of that... if you are saying this component can run 6GB data in foobar x32, that's another thing. It can't.
Also as I've said many times in the past, I would love to use your charts framework - comprehensive libary statistics would be my utopia - but it doesn't get off the starting block (for me!) because the core components crash foobar with the first computation of your framework.You simply refuse to use foobarx64 and JSplitter, but that's your problem. You can not ask foobar to handle +3gb of ram for things running within foobar without x64 binaries.
You are naturally looking after your self-interest, but if not derogatory, you are definitely over valuing engineering and under-valuing creativity; while not exclusive, neither is that easy.That's just your supposition about me.
Which is fine, everybody may have opinions. I would love this component to grow and support both sides.There has long been a vacuum of simple UI/front-end things here.That's for sure. But it has not been due to JS usage vs Web View, which is my point. SMP also supports HTML parsing and CSS, is just that some people avoid to use it because it breaks wine compatibility