Tests mit Optimierungen führen zu: Intrinsic has incorrect argument type! <4 x float> (<4 x float>, <4 x float>, i32)* @llvm.x86.sse41.dpps LLVM ERROR: Broken function found, compilation aborted! in Test.Filter.secondOrderPacked2 Ich kann es mit Kommandozeilen-Programmen nicht reproduzieren. Tests verursachen Speicherverletzungen mit neuem EE-Finalizer TestSuite: schönere Tests mit QC.forAll central importer definitions for startFunc and stopFunc Parameterized.Signal.derefFillPtr und derefChunkPtr zusammenlegen? CausalParam.reverbSimple -> Causal.reverb dazu müssten wir von RingBuffer eine Variante ohne Parameter schaffen oh da hängt so viel dran - es hängt wieder an alignedMalloc Causal-Variante müsste Speicher auf Haskell-Seite reservieren. Das könnte gehen, wenn wir ConstValue von LLVMSizeOf abfragen. comb-Filter, welcher Original am Anfang nicht enthält. Dazu müssen wir nur das Signal woanders in der Rückkopplungsschleife abgreifen. Wahrscheinlich ist es das: loopZero (mix >>> amplify gain >>> delayZero (subtract 1 time) >>> (Causal.delay1Zero &&& Cat.id)) do not write Bitcode files by default src/Synthesizer/LLVM/Server/Packed/Instrument.hs move ideas to ToDo or separate file Simple.Signal.alter Wieso wird da der exitState weggeworfen? Wird der überhaupt in Core gebraucht? Process.comb: If we swap 'delay' and 'amplify', then we would not amplify the initial zeros. Funktioniert optimize zuverlässiger, wenn man TargetTriple setzt? nein Mal an kleinen Beispielen untersuchen, woran es hakt. Fold: Brauchen wir das überhaupt, oder sollten wird einfach eine 'last' Funktion für Signale haben? Kleines Problem: 'Fold' funktioniert immer, während 'last' an leerem Signal scheitert. Server-Main: Subcommands statt Zahlen und Neuübersetzung dann könnte man auch Optionen abhängig von Kommando anbieten Iterator-Sachen könnten eigentlich alle auf einem List-Iterator basieren: Synthesizer.LLVM.EventIterator Synthesizer.LLVM.Storable.ChunkIterator Synthesizer.LLVM.Storable.LazySizeIterator Speech: sollte in öffentlicher Schnittstelle verbleiben, kann aber Exportliste vertragen, wie auch die Instrument-Module. Vielleicht sollte das ganze Server-Zeug mal in ein eigenes Paket. SampledSound: Tomatensalat-Sachen in 'server'-Verzeichnis ausgliedern aber dadurch wird man Abhängigkeit von pathtype in Library-Teil nicht los synthi-llvm-alsa: enthält Debug-Aufbauten, die nichts mit ALSA zu tun haben Cabal.Flag: debug, optimize besser: optparse-Optionen so können Benutzer beim Start entscheiden, ob sie generator.bc-Dateien haben wollen und ob der Optimierer eingesetzt werden soll merge scalar and vector computing Every process should contain a scalar and a vector loop body. We need converters from the vector to the scalar loop state and vice versa. There should be a generic constructor that constructs the vector loop body from the scalar one. Test.stereoFromMonoParameterizedSignal: move to Signal Test.multiMix, multiMixSignal: move to Process and Signal, respectively Optionen --optimize und --dump-bitcode kann man Simple.Process.Core als gemeinsamen Teil von Causal.Process und CausalParameterized.Process verwenden? Live-Sequencer/Sprachsynthese: Vergleiche synthetisierte Explosivlaute mit natürlichen bei nicht-gefundener Datei darf Synthi nicht abstürzen Filtermasken als Data-Files deklarieren Server.Test.speech, Test.tineFunctional: kurze Attack/Decay- und Release-Zeiten führen zu Abstürzen example:Test.allpassPhaser: crash osciPlain, loopConst -> eigenes Modul auch für constant, exponential usw. könnte manche Sachen in Test vereinfachen biete zwei Versionen für alle integrierenden Prozesse (osci, integrate, skip) Lag: Differenz wirkt erst auf nachfolgenden Wert Vorteil: Wenn man Initialwert x verlangt, bekommt man auch Initialwert x Sync: Differenz wirkt auf aktuellen Wert Vorteil: Verzögerungen hintereinandergeschalteter Integratoren addieren sich nicht Lag kann auf Sync aufbauen, aber nicht umgekehrt tests allpass and moog do not work reliably Has this to do with the replicateControlled enhancement? behaviour depends on environment: llvm-tf: GHCi completes all tests llvm-tf_2: GHCi segfault on the first test (Filter.secondOrderPacked) 'cabal build && synthi-llvm-test' allpass and moog fail with segfault 'cabal run test' aborts silently after unifilter Filt2L.bandpassParameter -> Private-Modul Private-Modul für Param word32 sollte privat sein Redundanz zwischen Signal.compileChunky und Process.compileChunky vermeiden Value-Module hinauswerfen Synthesizer.LLVM.Parameterized.Value Synthesizer.LLVM.Simple.Vanilla Parameterized.SignalValue: Gegenstück zu CausalParameterized.ProcessValue reparameterize :: Param q p -> Signal p a -> Signal q a reparameterize :: Param q p -> Causal p a b -> Causal q a b Does that simplify usage of functions that manipulate parameters, like replicateControlledParam stereoFromMonoParameterized trigger ? reverb: reverb -> reverbSimple oder ganz entfernen reverbEfficient -> reverb Änderungen -> ChangeLog Functional.stereoFromMonoParameterized statt Stereo.liftApplicative Signal.stereoFromMonoParameterized inkonsistente Namen: Causal.stereoFromMonoParameterized Causal.replicateControlledParam wir sollten lieber CSize statt Word32 für Größenangaben verwenden Parameter: Es gibt noch ein paar Param.get und Param.value, die nicht so einfach durch Param.with zu ersetzen sind. Kann man Param.T so umschreiben, dass intern direkt die get- und value-Funktion enthalten sind? Auf diese Weise könnten bei einem liftA2 f param0 param1 konstant und variable Parameter gemischt werden. Kann man damit Parameter-Sharing bei reverbEfficient erreichen? mit einer stop-Funktion ist es generell nicht mehr möglich, die Auswertung eines Stromes aufzuteilen, das hätte aber bisher auch schon an Prozessen versagt, die veränderliche Strukturen verwenden Soll es eigentlich erlaubt sein, "next" zweimal mit dem gleichen Zustand aufzurufen? In Process.skipVolatile wäre das ganz nützlich. Das kann schief gehen, weil z.B. Signal.storableVector eine Variable verändert "trigger" sollte Signal immer mit neuem Parameter starten können dazu ist es notwendig, dass man 'start' mehrmals pro 'create' aufrufen darf Würde das mit Lazy-StorableVector und StablePtr immer noch funktionieren? Storable: sollten wir überhaupt Storable-Klasse für Austausch mit LLVM-Funktionen nehmen? Storable-Bool ist möglicherweise nicht verträglich mit LLVM.load Sollten wir Strukturen mit Paaren zusammensetzen oder mit eigenem Pair-Datentyp? example:layzChord verursacht Stack dump: 0. Running pass 'X86 DAG->DAG Instruction Selection' on function '@fillsignal' das könnte an fehlender AVX-Unterstützung in LLVM-3.0 liegen unify Options in alsa, jack, render using optparse-applicative support --volume in 'render' we should certainly wait until optparse-applicative gives proper parser errors render: problem with end of file if I append zero, then I get an error from Gate.cons if I append one, then I get an error from SoX and the last release is missing How can I achieve, that all sounds are rendered completely? Test this with a stream of some mono sounds. in testsuite: use fractions with power of two denominator in order to avoid rounding errors this won't help for exponential curve and filters sometimes a sound is terminated without a release phase I suspect that our policy of how to interpret shortened vectors in CausalIO is problematic. tfp-laws e.g. Pos x, Pos y -> Pos (x:*:y) for simplification of type signatures if we cannot implement them in tfp, we should implement them in llvm-tf as Vector casts I assume that our "closed world instances" technique could help to apply such simplifications.