bgribble/mfp

Music For Programmers, a graphical patching language

mfp's Issues

Startup failures in GUI or DSP processes leave main process stuck

Ctrl-C from the console is handled OK now under "normal" circumstances, but if the GUI or DSP threads die during startup the app will still need a kill -9 to go away. Not nice!

Print version number on startup and at console

For debugging, it would be best to print the git checksum of the build along with a configured revision number.

Exception during processor init puts object in an undead state

Looks like incomplete initialization (interrupted by the exception) can leave the Processor in an untenable state. Main problem: makes it impossible to save the file.

DSP responses can get lost/delayed due to PCondition usage error

The lock and condition-variable management around mfp_response_cond (mfp_pyglue.c) has a race where the condition gets signaled but the waiter thread doesn't see it. The waiter thread needs to check for waiting responses BEFORE going to sleep for the first time.

snap~ with short time retrigger will crash DSP

[snap~ 1] will do it pretty quickly even with nothing connected

Changing object name should cause a resort of the objects list

Currently the object list stays out of sorted order until a quit and reload.

I think this just needs a TreeDisplay.update called after the name change is processed.

Changing name of a RecvVia doesn't take effect (saved file has old name)

I tracked this down to misunderstanding in the main.py wrappers for MFPApp. MFPCommand.rename_obj was calling assign() directly rather than obj.rename().

Add file load/save functionality to UI

finally -- with the Prompter we can have a simple prompt for filename

It's not that robust and it's not a file selector but at least it doesn't require the console any more

Add tooltip support for documentation about objects and ports

For now, it's OK to just show a HUD message with the tooltip; in fact I sort of like that as a long-term answer, I hate tooltip bubbles!

save_file does not include correct display_type for plots

Should always be "plot", with "plot_type" either "scatter" or "signal".

Fix broken tests

• mfpdsp tests are very broken -- SIGSEGV on a few
• mfp tests still fail on the file I/O since I haven't updated those tests recently

Multi-line statement suites in console don't work

Each line in a multiline statement suite is sent for compilation separately by the mfp.gui.ConsoleMgr. This doesn't work!

Usage of SSE instructions in mfpdsp needs review

Early testers are reporting more problems than I would have expected with this. Disabling all the x86intrin calls by not defining MFP_USE_SSE is pretty drastic, and not well tested. I need to look at this and either slice the configuration more finely or test all the options.

Release mfp 0.02

• Make git tag
• Create a CHANGELOG
• Create an ANNOUNCE
• Push the release

Plot element: Support log axes

Need log axes in both X and Y, with decade and octave (log 10/log 2) scaling.

Automatically wrap Python callables if there's no builtin or patch file with that name

I don't see why this shouldn't work:

[ " " (
|
[re.compile] 
|   ["this is a string"(  
|   |
[re.split] 
| 
[print] 

IOW, if there's no builtin or patch file for a [processor] init, see if the init_type evaluates to a Python callable. If it does, determine the arity by introspection and make a proper Processor.

osc~ sometimes changes apparent pitch when inlet 1 is driven by a signal

A patch like this had some unexpected output:

[phasor~ 1]
|
[>~ 0.5] 
| 
[*~ 440]
   |
[osc~]
|
[out~]

This is a beep... beep... beep patch. After some time, the subjective pitch of the osc~ shifted down some cents, corresponding with me dragging a UI element. It stayed at the lower pitch level for a while (10s of seconds to a minute) then shifted back up.

ampl~ rms algorithm is broken

Just a reminder to fix this in the near future -- the "RMS" output of ampl~ is nothing of the kind right now, it's just a dumb low pass.

posix_ipc not listed in the requirements

fps@mango:~$ /usr/local/bin/mfp [ 0.000 main] RPCWrapper: registering class <class 'mfp.rpc_wrapper.RPCWrapper'> RPCWrapper init_builtins: initializing 17 builtin DSP processors phasor~: init_builtin_phasor called [ 0.003 main] RPCWrapper: registering class <class 'mfp.dsp_slave.DSPObject'> DSPObject [ 0.003 main] RPCWrapper: registering class <class 'mfp.dsp_slave.DSPCommand'> DSPCommand [ 0.029 main] RPCWrapper: registering class <class 'mfp.main.MFPCommand'> MFPCommand [ 0.029 main] RPCWrapper: registering class <class 'mfp.gui_slave.GUICommand'> GUICommand [ 0.029 main] Main thread started, pid = 28107 [ 0.041 dsp] DSP thread started, pid = 28108 jack_startup: samplerate=48000, blocksize=1024 DSP params: 48000.0 1024.0 [ 0.132 gui] GUI thread started, pid = 28126 Exception in thread Thread-15: Traceback (most recent call last): File "/usr/lib/python2.7/threading.py", line 552, in __bootstrap_inner self.run() File "/usr/lib/python2.7/threading.py", line 505, in run self.__target(*self.__args, **self.__kwargs) File "/usr/local/lib/python2.7/dist-packages/mfp-0.01-py2.7-linux-x86_64.egg/mfp/gui_slave.py", line 233, in clutter_proc from mfp.gui.patch_window import PatchWindow File "/usr/local/lib/python2.7/dist-packages/mfp-0.01-py2.7-linux-x86_64.egg/mfp/gui/patch_window.py", line 16, in <module> from .modes.patch_edit import PatchEditMode File "/usr/local/lib/python2.7/dist-packages/mfp-0.01-py2.7-linux-x86_64.egg/mfp/gui/modes/patch_edit.py", line 17, in <module> from ..plot_element import PlotElement File "/usr/local/lib/python2.7/dist-packages/mfp-0.01-py2.7-linux-x86_64.egg/mfp/gui/plot_element.py", line 15, in <module> from .xyplot.scopeplot import ScopePlot File "/usr/local/lib/python2.7/dist-packages/mfp-0.01-py2.7-linux-x86_64.egg/mfp/gui/xyplot/scopeplot.py", line 12, in <module> from posix_ipc import SharedMemory ImportError: No module named posix_ipc

Deleting a [sig~] can cause a segfault

I haven't looked at this code in a while, it may just be crappy. I saw a segfault just creating one and then deleting it, not connected to anything else

README does not mention pluginfo

Instructions should include

$ cd pluginfo
$ python ./setup.py install

Add [osc_in] and [osc_out] objects

[osc_in] receives messages on an arbitrary URL

[osc_out] should either try to guess its arg types or possibly support a specific tagged input format? Maybe a 3-input object, where the inputs are URL, type, and value, and if you don't pass in a type the type of the value is used.

Remove locking from mfp_dsp_send_response_*

This should be done lockfree like parameter sends are

Add [send~], [recv~], and signal vias

These are pretty important if layers are really going to be a significant program structuring mechanism.

Add meaningful command-line parsing

At minimum:

• JACK inputs/outputs
• python init/RC files to load
• patch search path
• OSC port
• no_gui/no_dsp

Improvements to slider/bar graph

• No label needed
• Log or linear scale/ticks
• Horizontal or vertical
• Pull-up or pull-down.
• Control/edit mode with keys to change scale, whether scale is displayed, etc

"Graph-on-parent": show exported UI when a user patch is loaded in another patch

The easy way to do this: look for a layer named "Interface", and draw all non-connection, non-via objects in a shrink wrapped bounding box. This would just require a slightly enhanced ProcessorElement.

This could be refined, for sure, but the above is a 90/10 solution.

Locking and memory allocation in JACK callback are naughty

There's a single lock access in each JACK callback cycle, for a lock that is only held for a few microseconds. That may be tolerable, but if there's a lockfree way to do it I should try it.

builtin_buffer.c allocates its shm segment on configure. I knew that was bad when I wrote it. This can be fixed by having a preconfig hook which gets called from the non-RT thread when the config request is set. It can allocate memory etc. and leave pointers in the private data structure.

Pass latency changes up to the patch level (?)

This is annoying. Patches that do overdubbing, like the looper, need to internally compensate for e2e latency. This is going to mean a [del~] somewhere and that [del~] needs to know how much to delay.

Could this be a separate processor, that only does this kind of latency compensation?

Either [in~] or [out~] doesn't accept init args properly

In a test with this patch:

[in~ 0]    [in~ 1]
|             |
[out~ 0]  [out~ 1] 

Which should be a passthru... input 0 is duplicated on both outputs.

I think this points to [in~] always getting JACK input 0 but I allow that there might be some other explanation

Create control mode for enum (number box)

• Increase/decrease displayed digits
• set upper and lower bounds on value

[plugin~] backtraces if there are hints

This is just untested broken code in pluginfo.py

Sometimes the string "__patch__" gets in PatchWindow.selected

I have seen this after trying to connect a signal output to a non-signal input

It must come from the object list display somehow, after connect-mode fails to make the connection

Causes a traceback in the log that keeps recurring

Handle Ctrl-C correctly and exit cleanly

Lots of threads --> lots of mess to clean up

but this needs to be done

Console statements should use only Evaluator globals

Names bound by the interactive console should be visible to the running patch. If we pass a locals dict to the exec() call, any new names will be put in the locals dict and so aren't visible to the patch

Removing the (optional) locals dict from the exec() and exec_file() calls in mfp.evaluator.Evaluator should fix this.

Input modes sometimes stack incorrectly

When there are several active minor modes, sometimes "stacking" of the modes can cause unintended input-stealing.

For example:

m Bang RET -- create Bang message

c a p print -- start connection to a new print processor

M1DOWN [outside of print box] -- oops, print is unselected before complete

M1DOWN [inside print box] -- selects print

RET -- starts editing

RET -- accepts edits and completes creation

But now you are stuck with the Connection mode in the mode stack and unable to complete the connection, because every RET either starts editing or completes editing of the print object

ClutterColor.from_string binding varies from one version to another

This can result in named colors never working.

Two fixes: don't use named colors, or wrap usage to check for the return value (either a ClutterColor, or a tuple).

Plot element: Draw curve from buffer~

Most of the tools are there, but need to add a renderer in scopeplot.py to intelligently redraw a waveform from a buffer~ shared memory buffer

Regularize tab/space and other formatting issues

I'll leave this issue open to capture commits on this topic

Learned OSC methods are not deleted on object destroy

This throws a bunch of tracebacks if OSC input is received that would have been directed to a deleted object.

Support multiple open patches for editing

Most of the support for this is already there, but need to finish it out and flush any bugs that pop up.

Refactor mfpdsp parameter setting

Right now there's a race in parameter setting on the C side which could result in a crash, I think. The Python glue code can change the params hash table while the process thread is looking at it. But unwinding it won't be all that easy. The mfp_reqdata config queue is part of the solution.

Add clip playback/looping to buffer~

Simple support for playing the capture buffer oneshot and looping between set points should give a basic framework to build looping samplers and similar stuff.

In practice I think the best way to do this with multiple capture channels is to have a single audio output and use a channel mask to control mixing the capture buffers to this output. Maybe later we need some channel operations, such as mix/move etc, to modify in-place

Add API to load a shared library into mfpdsp

This should be pretty straightforward. dlopen(), find an init method, and call it.

Need a suitable test library to try out as well.

[plugin~] segfaults loading CALF Reverb

Not sure what this is, will bisect to find the spot

DSP: Add LADSPA plugin host

LADSPA first, LV2 later.

Correctly handle JACK block size change notifications

This is completely punted right now. The process() part would work, since we use mfp_blocks to pass the data around, but the processors need a method to re-allocate their internal storage if any.

Slider/meter: Enhance scale options

This was originally in #8 but I don't think it's as important as the other things in that ticket.

There's already a "scale" gui parameter which can be set to "log" or "linear" and will set a corresponding value in the SlideMeterElement. But it's not implemented in the draw_cb.

Also, could add a multislope option to support audio levels better -- with dB scaling, you want the top ~10 dB to be relatively larger, with 2 or 3 different dB scale slopes through the long range of the meter.

Clean up repo in advance of 0.01 announcement

Remove unused/confusing docs, add source tree roadmap, in general tidy the place up a bit

Use package resources to load glade file

package_data is already installed, just need to use the pkg_resources API to find the .glade file.