fengalin / gstation-edit Goto Github PK

Metada in setup still correspond to version .5 in beta.
Also check if there is a convention that would not limit to X11 as a graphical application type.

Preparation for release 1.0.0

See #22 for a primary analysis of the format.

Python 3 support would be a plus. In order to achieve this, the two following topics need to be addressed:

1. Fix Python 2 styles in order to conform to Python 3. There should not be much left as I tried to upgrade the code base when I fixed the coding convention.
2. Find a replacement for pyalsa which is only available for Python 3. This is not that easy. So far, I spotted the following candidates:

• ALSA gi : a gobject instrospection library for ALSA. Support for the MIDI sequencer is included. A POC would be necessary to confirm that all features needed by GStation-Edit are available. The drawback is that it doesn't seem to be included in distributions nor in Pypy, so it is probably not a good idea to rely on it.
• pyAlsaAudio : supports Python 2 & 3 and part of Pypi. Unfortunately, it doesn't support the MIDI sequencer as mentioned here. It might be an opportunity to give a hand on the project.

In the mean time, the README file should reflect that Python 2.7 is a requirement and the setup script should restrict to using Python 2.

When building a message to send or export, the developer must call the method build_sysex_buffer after the message's construction. Following the same principle as for parse_data_buffer, build_sysex_buffer could be called in constructor whenever necessary.

When GStation-Edit connects to the J-Station, the program current selected on the unit is not automatically selected in the UI.

The application's icon displayed in the DE is the default GTK icon. The UI definition refers to the multimedia-volume-control icon, which is one of the icon names proposed by glade. Maybe this name is not available on every platform or not available for GTK-3.

It might be the opportunity to design a dedicated icon instead.

Describe what the project handles (MIDI sysex messages, communication, import / export).

Add screenshots showing the UI in the README file so that potential users get an idea of what the application can do for them.

GStation-Edit allows editing the names for the presets (programs), but nothing allows storing the new name to the J-Station.

Add an option to store programs with a new name to the J-Station.

On loopback:
Attempting to connect to Midi Through Port-0 and Midi Through Port-0
Incorrect checksum got: x7a, expected, x00 - index: 11/11
['x00', 'x00', 'x10', 'x7e', 'x54', 'x40', 'x00', 'x01', 'x00', 'x01', 'x00']
full buffer: index: 12/17
['xf0', 'x00', 'x00', 'x10', 'x7e', 'x54', 'x40', 'x00', 'x01', 'x00', 'x01', 'x00', 'x00', 'x00', 'x01', 'x7b', 'xf7']

MIDI configuration management is handled in the Main Window (and duplicated in the sniffer's app). It should be possible (and would make more sense with regard to the separation of concerns principle) to handle everything in the MIDI dlg.

The J-Station features the following options:

• Stereo or mono output.
• Dry track (before/after effects) S/PDIF output.
• Digital output level.
• Cabinet emulation activation/bypass.
• MIDI loop back.
• MIDI channel selection.

GStation-Edit already read these options during the connection to the J-Station after the WhoAmI request. The aim of this enhancement is to build a UI that allows viewing and changing these options.

Possible designs:

1. Add a new rack unit to the main window. Pros: easy to implement. Cons: take space for functions that are used every once in a while: not the same level as all the other effects or preset selections.
2. Add a dedicated modal dialog. Pros: clean and save real estate. Constraint: Need a menu with options to open the modal (this should be easy to implement in GTK-3 style), which would also be a good infrastructure for other features.

Implement an application to dump messages exchanged between J-Edit a the J-Station.

Give hints on how to investigate problems.
Example:

• Diagnose J-Station connection failure.

When sliding a scale widget to its maximum value, the actual value selected is variable and never the maximum value the scale can reach. When moving the mouse out of the main window, we get a little higher value, but still not the maximum and still in some sort of random uncontrollable way.

The scale widget should allow reaching the maximum value by moving the mouse to its far right.

The new header bar features buttons to undo, store, open utility settings and open MIDI selection. This should appear on the screenshots of the README file.

Installation using distutils doesn't work anymore. New sub-packages are not distributed.

The MIDI event factory does the job, however it relies on an iteration in a list to figure out which event to instantiate.

The proposal is to first distinguish the event using the seq_event.type field. This allows making the difference between CCEvent, PRGChange or SysExEvent. Then in the case of a SysExEvent, the procedure_id can be used as a hash value to find the appropriate class.

The following sequence is not reflected in the UI:
On the J-Station

• Push Store once.
• Change program on the J-Station.
• Push Store.

The new program should be selected on the application with the changes.
The following messages are sent:

• J-Station => NotifyStore (x22). Version: 1, prg nb: 7

• J-Station => OneProgramResponse (x02). Version: 1, prg bank: user, prg nb: 7, has_changed: 0, prg name: Wide Acoustic, prg data: ['00: 01', '01: 28', '02: 02', '03: 04', '04: 06', '05: 00', '06: 00', '07: 00', '08: 127', '09: 09', '10: 48', '11: 69', '12: 71', '13: 52', '14: 90', '15: 00', '16: 01', '17: 00', '18: 32', '19: 01', '20: 00', '21: 30', '22: 20', '23: 60', '24: 20', '25: 01', '26: 01', '27: 00', '28: 00', '29: 04', '30: 00', '31: 22', '32: 01', '33: 03', '34: 52', '35: 99', '36: 99', '37: 03', '38: 127', '39: 127', '40: 02', '41: 127', '42: 00', '43: 255']

Use a logger instead of print statements commented in or out during debugging.

Scale widgets display raw values: the values which are exchanged on the MIDI channels.
The UI should display human readable values. The labels could show the associated units.

When changing the program on J-Station, the following message appears in the console:

Could not find key control.param. 
event is invalid PrgChangeEvent. channel: 0, param: -1, value: 8

The program is properly changed in the UI though.

For many widgets, current model for signals involves using a dictionary to define handlers. The main window is then in charge of connecting the handlers.

It would be more explicit to connect the widget to the handlers in place upon initialization.

The MIDI connection dialog allows defining the sysex channel. Currently, only channel 1 is used.
The selected channel should be used instead and persisted. This also applies to the sniffer.

Application settings should persist between session.
Examples of settings:

• MIDI ports for which a connection succeeded.
• Default location for import / export of programs.

When J-Edit disconnects, it sends a sequence of (param=120, value=0) and (param=64, value=0) on all channels (0 to 15), then it disconnects from the MIDI port.

J-Station replies with the same sequence.

First of all, thanks to fengalin for providing a way to operate my old J-Station under UX. And I am not a programmer :-).

I am facing an issue when trying to set up the environment. The installation stops and terminates with the output below.
I there any suggestion what I could change or do to make the installation?

Thanks for any help!

Kind regards

Harald

+++++
Run on

Linux harald-optiplex3060 5.19.0-1009-lowlatency #10-Ubuntu SMP PREEMPT_DYNAMIC Fri Oct 14 20:14:19 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

+++++
$ pip install --force-reinstall dist/gstation_edit-2.0.3-py3-none-any.whl
Defaulting to user installation because normal site-packages is not writeable
Processing ./dist/gstation_edit-2.0.3-py3-none-any.whl
Collecting pyalsa@ https://github.com/alsa-project/alsa-python/archive/refs/tags/v1.2.7.zip
Using cached https://github.com/alsa-project/alsa-python/archive/refs/tags/v1.2.7.zip
Preparing metadata (setup.py) ... done
Collecting pygobject
Using cached PyGObject-3.42.2.tar.gz (719 kB)
Installing build dependencies ... error
error: subprocess-exited-with-error

× pip subprocess to install build dependencies did not run successfully.
│ exit code: 1
╰─> [41 lines of output]
Collecting setuptools
Using cached setuptools-65.6.3-py3-none-any.whl (1.2 MB)
Collecting wheel
Using cached wheel-0.38.4-py3-none-any.whl (36 kB)
Collecting pycairo
Using cached pycairo-1.22.0.tar.gz (342 kB)
Installing build dependencies: started
Installing build dependencies: finished with status 'done'
Getting requirements to build wheel: started
Getting requirements to build wheel: finished with status 'done'
Preparing metadata (pyproject.toml): started
Preparing metadata (pyproject.toml): finished with status 'done'
Building wheels for collected packages: pycairo
Building wheel for pycairo (pyproject.toml): started
Building wheel for pycairo (pyproject.toml): finished with status 'error'
error: subprocess-exited-with-error

    × Building wheel for pycairo (pyproject.toml) did not run successfully.
    │ exit code: 1
    ╰─> [15 lines of output]
        running bdist_wheel
        running build
        running build_py
        creating build
        creating build/lib.linux-x86_64-3.10
        creating build/lib.linux-x86_64-3.10/cairo
        copying cairo/__init__.py -> build/lib.linux-x86_64-3.10/cairo
        copying cairo/__init__.pyi -> build/lib.linux-x86_64-3.10/cairo
        copying cairo/py.typed -> build/lib.linux-x86_64-3.10/cairo
        running build_ext
        Package cairo was not found in the pkg-config search path.
        Perhaps you should add the directory containing `cairo.pc'
        to the PKG_CONFIG_PATH environment variable
        No package 'cairo' found
        Command '['pkg-config', '--print-errors', '--exists', 'cairo >= 1.15.10']' returned non-zero exit status 1.
        [end of output]
  
    note: This error originates from a subprocess, and is likely not a problem with pip.
    ERROR: Failed building wheel for pycairo
  Failed to build pycairo
  ERROR: Could not build wheels for pycairo, which is required to install pyproject.toml-based projects
  [end of output]

note: This error originates from a subprocess, and is likely not a problem with pip.
error: subprocess-exited-with-error

× pip subprocess to install build dependencies did not run successfully.
│ exit code: 1
╰─> See above for output.

note: This error originates from a subprocess, and is likely not a problem with pip.
+++++

Installation is broken again:

• setup.py should be executable.
• exception:
  Traceback (most recent call last):
  File "/home/francois/.local/bin/gstation-edit", line 26, in
  from gstation_edit.app import GStationEdit
  File "/home/francois/.local/lib/python2.7/site-packages/gstation_edit/app.py", line 27, in
  from .main_window import MainWindow
  File "/home/francois/.local/lib/python2.7/site-packages/gstation_edit/main_window.py", line 31, in
  from .utilities_dlg import UtilitiesDlg
  File "/home/francois/.local/lib/python2.7/site-packages/gstation_edit/utilities_dlg.py", line 23, in
  from .messages.utility_settings_resp import UtilitySettingsResponse
  File "/home/francois/.local/lib/python2.7/site-packages/gstation_edit/messages/utility_settings_resp.py", line 20, in
  from .jstation_sysex_event import JStationSysExEvent
  File "/home/francois/.local/lib/python2.7/site-packages/gstation_edit/messages/jstation_sysex_event.py", line 20, in
  from ..midi.event import MidiEvent
  File "/home/francois/.local/lib/python2.7/site-packages/gstation_edit/midi/event.py", line 21, in
  from .event_resp_factory import *
  ImportError: No module named event_resp_factory

When GStation-Edit attempts to connect to the J-Station, the default cursor is displayed. The cursor used to switch to waiting but the behaviour was lost when porting to GTK-3.

See how applications handle this now. It might be a waiting animation. A message could enhance the user experience: either "Attempting to connect..." or something mentioning the MIDI ports being probed.

User should be able to use the context menu to copy / paste a program.

When changing digital out level, the following exception occurs:
Traceback (most recent call last):
File "/home/francois/Projects/gstation-edit/gstation_edit/ui_core/scale_parameter.py", line 66, in handle_change_value
self.set_value(int_value)
File "/home/francois/Projects/gstation-edit/gstation_edit/ui_core/scale_parameter.py", line 58, in set_value
self.value_lbl.set_text(self.str_value)
AttributeError: 'NoneType' object has no attribute 'set_text'

Allow importing and exporting program data.

J-Edit exports a single program in "sysex" format with syx extension.

The following messages are exchanged:

• J-Edit => Uknonw sysex [RECEIVE_PRG_NAME] (x15). Version: 1
• J-Station => ToMessageResponse (x7f). Version: 1, request procedure: x15, message: OK (0)
• J-Edit => Uknonw sysex [RESET_MODIFIED] (x19). Version: 1
• J-Station => ToMessageResponse (x7f). Version: 1, request procedure: x19, message: OK (0)

In the event of an exception when a file is read or written (import / export), a message should be displayed for the user to be aware of the problem.

One solution would be to use notifications. Another would be to display a good old annoying popup message...

When program is modified, it could notify the UI automatically, instead of the UI requesting for an update and applying changes.

At the moment, the only way to apply changes to a preset is to push the Store button on the J-Station. The UI should include a feature to send a notification to store the update.

This is a sequence using JEdit:

• J-Edit => ReceiveProgramUpdate (x61). Version: 2, Prg bank: -1, prg nb: -1, has_changed: 0, prg name: le poirier III, prg data: ['00: 01', '01: 36', '02: 05', '03: 12', '04: 19', '05: 00', '06: 00', '07: 00', '08: 127', '09: 07', '10: 08', '11: 67', '12: 26', '13: 49', '14: 73', '15: 05', '16: 00', '17: 00', '18: 31', '19: 00', '20: 02', '21: 53', '22: 10', '23: 55', '24: 60', '25: 00', '26: 00', '27: 00', '28: 26', '29: 06', '30: 73', '31: 39', '32: 01', '33: 01', '34: 15', '35: 70', '36: 10', '37: 04', '38: 127', '39: 127', '40: 02', '41: 127', '42: 00', '43: 255']
• J-Edit => OneProgramResponse (x02). Version: 1, Prg bank: 1, prg nb: 2, has_changed: 0, prg name: le poirier III, prg data: ['00: 01', '01: 36', '02: 05', '03: 12', '04: 19', '05: 00', '06: 00', '07: 00', '08: 127', '09: 07', '10: 08', '11: 67', '12: 26', '13: 49', '14: 73', '15: 05', '16: 00', '17: 00', '18: 31', '19: 00', '20: 02', '21: 53', '22: 10', '23: 55', '24: 60', '25: 00', '26: 00', '27: 00', '28: 26', '29: 06', '30: 73', '31: 39', '32: 01', '33: 01', '34: 15', '35: 70', '36: 10', '37: 04', '38: 127', '39: 127', '40: 02', '41: 127', '42: 00', '43: 00']
• J-Station => ToMessageResponse (x7f). Version: 1, request procedure: x61, message: OK (0)
• J-Station => ToMessageResponse (x7f). Version: 1, request procedure: x02, message: OK (0)

Note the has_changed parameter kept to 0 for both outgoing messages and the parameter 43 which switched from 255 to 0 (is this the Store led?).