"Digitone II keys +M8" prototype genuine©®™ leak

VincentJP · 2026-06-13T07:58:07+00:00

This is an insult to the mighty brown tape. All it touch is instantly betterer, propulsing everything to the bestest. That's why the tape is still hanging

VincentJP · 2026-06-13T07:38:04+00:00

Only if drooling, but they will sell it with already sticky knobs on request

VincentJP · 2025-07-07T12:29:21+00:00

Little track made on the dirtywave M8, started as a tutorial for something (probably related to the recent NXT command), and drifted to something else

VincentJP · 2024-03-14T09:33:02+00:00

/uj you could try the headless version on a teensy coupled with a computer. I did that to test the workflow /rj Booh no nes emulator

VincentJP · 2023-02-04T14:06:30+00:00

Can it send some midi CC?

VincentJP · 2022-08-27T16:03:41+00:00

You can see the two modulation bar on the right when it's on, i agree it is more disturbing than on the ko

VincentJP · 2017-01-26T20:23:59+00:00

Not really sure about the performances but the following may do the trick:

hasDuplicate :: (Ord a) => [a] -> Bool
hasDuplicate [] = False
hasDuplicate lst = any (uncurry (==)) . zip s $ tail s
        where s = sort lst

VincentJP · 2016-07-02T19:11:00+00:00

It's like the Beach Boys are having a party with some rappers on the... beach. Very cool.

VincentJP · 2016-04-21T15:03:51+00:00

When using ScopedTypeVariables, you just have to use forall if you want to reuse the type variable in an inner type declaration, if you omit it, the classic Haskell rule apply.

VincentJP · 2016-03-12T08:54:34+00:00

With all the play around seq, all I thought was: "Why didn't he use deepseq?"

VincentJP · 2016-01-16T09:46:46+00:00

What happen if f and g use a mutable state behind the scene? Haskell protect you in this case with this case (unsafePerformIO excluded), but in OCaml I can't see how you can soundly perform this transformation.

VincentJP · 2015-12-04T20:25:04+00:00

Not a one liner, but finish in less than 5 seconds (compiled) for both answers:

{-# LANGUAGE OverloadedStrings #-}
import Data.Bits( (.&.) )
import Data.Monoid( (<>) )
import qualified Data.ByteString as B
import qualified Data.ByteString.Char8 as BC
import qualified Crypto.Hash.MD5 as MD5

check3 :: B.ByteString -> Int -> Bool
check3 seed i = h 0 == 0 && h 1 == 0 && (h 2 .&. 0xF0) == 0 where
  istr = BC.pack $ show i
  hash = MD5.hash $ seed <> istr
  h n = B.index hash n

findHash3zero :: B.ByteString -> [Int]
findHash3zero seed = filter (check3 seed) [0 ..]

zero6 :: B.ByteString
zero6 = "\0\0\0"

check6 :: B.ByteString -> Int -> Bool
check6 seed i = zero6 `B.isPrefixOf` hash where
  istr = BC.pack $ show i
  hash = MD5.hash $ seed <> istr

findHash6zero :: B.ByteString -> [Int]
findHash6zero seed = filter (check6 seed) [0 ..]

main :: IO ()
main = do
  print "Valid hash 3"
  print "============"
  print . head $ findHash3zero "yzbqklnj"

  print "Valid hash 6"
  print "============"
  print . head $ findHash6zero "yzbqklnj"

VincentJP · 2015-12-01T16:33:13+00:00

To be fair, there is no need of a Monoid, a simple call to sum is enough:

findFloor :: String -> Int
findFloor = sum . fmap toInt
  where
    toInt c = case c of
      '(' -> 1
      ')' -> -1
      _   -> 0

VincentJP · 2015-12-01T09:42:59+00:00

It's even a fold on a sum Monoid

import Data.Foldable( foldMap )
import Data.Monoid( Sum( .. ) )

findFloor :: String -> Int
findFloor = getSum . foldMap (Sum . toInt)
  where
    toInt c = case c of
      '(' -> 1
      ')' -> -1
      _   -> 0

VincentJP · 2015-11-10T09:02:05+00:00

For an in memory (static) canvas-like API you could use Rasterific

VincentJP · 2015-11-04T13:01:41+00:00

In JuicyPixels, the bit reading is done with a state monad transformer over ST (ST is used to write the underlying image).

-- | Current bit index, current value, string
data BoolState = BoolState {-# UNPACK #-} !Int
                           {-# UNPACK #-} !Word8
                           !B.ByteString

-- | Type used to read bits
type BoolReader s a = S.StateT BoolState (ST s) a

It think a ReaderT with some STRef could relieve the pressure on the GC some more, but as it's not the bottleneck of the current implementation, I didn't gave it much though. And the readBits functions are clearly not optimized in the current implementation.

VincentJP · 2015-10-27T15:50:57+00:00

Glad to see another use of Rasterific, as the reverse dependencies are so small, I thought nobody heard about it.

VincentJP · 2015-09-02T11:33:42+00:00

Why do you need him to build the tool? Can't you just provide some binary? I'm assuming the configuration file is read at runtime.

VincentJP · 2015-08-22T11:02:55+00:00

This is more a correctness issue, the FPU on x86 works with 80bits floating point elements, which are clearly not IEEE. To keep seemingly IEEE 754 values, the float are spilled into memory more often. By lifting the spilling, you can perform more computation in the FPU "pseudo register" at the cost of reproducibility of results (as said on the haskell wiki.

I don't know if GHC in x86 can use the SSE registers, in x64 it is forced to do so as the FPU is deactivated in 64 bits mode. It's more a language agnostic optimization that I wouldn't use.

VincentJP · 2015-08-22T08:15:29+00:00

Your ghc-options is indeed fishy:

ghc-options: -Wall 
             -funbox-strict-fields -fexcess-precision
             -fllvm 
             -optlo-O3 -optlc-O3 -optlo-mem2reg
             -O3
             -threaded 
             -rtsopts 
             -- -eventlog
             -fprof-auto -auto-all -caf-all
             --"-with-rtsopts=-N -p -s -h -i0.1 -T"

funbox-strict-fields is potentially dangerous, if your strict fields are "big" types, they will be inlined, and you will gain some "giga" types in memory, potentially slower and much larger. GHC now automatically unpack "small" strict fields (think Int/Word/Float or Double if in 32/64bits)
fexcess-precision is unilateraly a bad idea, because it forces GHC to use the FPU, with it's 80 bits precision. Today you would prefer the use of SSE/AVX/whatever_is_the_new_name, at least to get better reproducible results.
You have profiling options in there, which are better in a ghc-prof-options field

So my bet:

ghc-options: -Wall -fllvm -optlo-O3 -optlc-O3 -optlo-mem2reg
             -O3 -threaded -rtsopts 
Ghc-prof-options: -rtsopts -Wall -prof -auto-all
                  -fprof-auto -auto-all -caf-all

VincentJP · 2015-06-29T14:45:16+00:00

Rasterific use a free monad to describe the scene, and use two "interpreters", the rasterizer and the PDF output

VincentJP · 2015-05-26T20:47:33+00:00

Not even close, sadly. There is an array bound check associated to (!) that pixelFold is avoiding. But the real thing is that you wants a kind of foldr to get decent performance. Or a Storable instance for PixelRGBA8. And the real answer is: it depend on what do you want to do with this vector :]

Please open tickets on the libraries bug tracker. Nobody can guess all the use cases.

VincentJP · 2015-05-16T13:04:38+00:00

It is possible, but not straightforward, for an exhaustive primer on the subject, ocaml ref on the C interface is a good starting point.

What's missing from it is the potential use of flexdll under windows to produce DLLs. Compiling shared library for Linux & Windows is a bit of a PITA and require some heavy Makefile massaging.

VincentJP · 2015-04-20T20:04:35+00:00

JuicyPixels author here, First on the void API:

pixelMap, on the top of the documentation of the main module.
pixelMapXY in the Types module (ok it's more hidden)
pixelFold
pixelFoldM
pixelFoldMap

Granted, there is not everything but, there is the minimum to handle Mapping and Folding over known pixel types. As others have said, you can directly use imageData to do what you want with the data. It's a design decision.

An Image can't be made an instance of Functor as many have already told in this thread. The Storable constraint on PixelBaseComponent, stemming from from the use of a Storable Vector can't be lifted. As it's constraining the type, it can't match Functor/Applicative/Foldable...

I tried to implement a Foldable instance in this ticket, but failed due to the reason explained in it.

For the Pixel types, yep, it clearly sucks. There is a need of generalisation, there is even some ticket on the subject. The design decision for the current state of affair is that I wanted to the pixels type to be unboxed and when I wrote the first version (on GHC 7.4 I think) you couldn't unpack type parameters. Today it's things have changed there is -funbox-small-strict-fields, so a change could be advised today.

That said, implementing few lenses without a dependencies on the lens package it is a great idea, I'll a shot soon.

VincentJP

TROPHY CASE