View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0000124 | Cinelerra-GG | [All Projects] Bug | public | 2019-02-03 20:26 | 2019-06-04 03:15 |
Reporter | Pierre | Assigned To | PhyllisSmith | ||
Priority | normal | Severity | feature | Reproducibility | always |
Status | closed | Resolution | fixed | ||
Platform | i7-3770k, 32GB(ram), GTX-750Ti | OS | Linux Mint Mate | OS Version | 18.3 |
Product Version | |||||
Target Version | Fixed in Version | ||||
Summary | 0000124: Test with "ShuttleXpress" and "ShuttlePRO v2" | ||||
Description | As the previous file on the same subject has been closed, I am opening a new one I am currently testing the use and preferred configurations of CONTOUR's two Jog-shuttle Type controllers. I started a small documentary type editing from an old shooting I had done a few years ago but which I had never edited before. It will allow me to evaluate the usefulness of these controllers in a real editing work. I will start this editing using the most rudimentary model, the "ShuttleXpress". Once I have configured it to my liking, I will replace it with "ShuttlePRO v2" and apply the same process to continue editing. I don't think I'm going to stretch this test over a period of more than a few days. I will summarize this experience in the Forum once this test is completed. But I will indicate here the problems I will find, if any, as I go through my test. | ||||
Tags | No tags attached. | ||||
I think we can close this subject. It is likely that the ShuttleProv2 that will be sold will all have this limitation of buttons 14 and 15 not working with the standard Linux driver (but working with the specific CinGG driver, with the limitation of a single active instance). I don't think Contour Design Inc. will ever fix this problem since they don't offer official support for Linux and they don't have this problem on Windows and MacOS. However, apart from this slight limitation, Shuttles Express and ShuttleProv2 work quite well under Cinelerra-GG and are very useful in the actual editing work. |
|
I guess not after all, as I spent some time reviewing what might be useful to know and really did not think anything would be. If K14 and K15 do not do anything, it is most likely that they just switched out the original board for that same design board. GG thinks that the reason it took so long is because probably the board "fix" was not done in the United States and that the actual problem was not correctly communicated to the person who did the actual work. Also, we do not have any improvement for shuttle wheel/dial operation. Should I close this issue out or do you feel that there is something seriously wrong that is easily reproducible? |
|
Phyllis, do you still want an uncorrected shuttle dump? | |
What a big disappointment. GG will want to get some kind of dump of your "new - still broken" Shuttle. He will provide the instructions later (in the middle of working on masking), but if I forget, remind me! | |
My "ShuttleProv2" was returned to me today by Contour Design Inc. I finally sent them my device 10 days ago, so they could update its firmware, so that its buttons 0000014 and 0000015 could work under Linux. I had contacted Mr. Moyer de Contour and had a very courteous correspondence with him. He therefore had me send my ShuttleProv2 to have his firmware corrected according to the instructions that had already been sent to him previously in his correspondence with Phyllis. Contour took care of the transport to and from the device. So my ShuttleProv2 came back today in perfect condition; without a scratch, except... the problem is not fixed... buttons 0000014 and 0000015 still don't work under the standard Linux driver... I don't know what they did, there was no indication in the package. Maybe they simply put back the same (last?) firmware that is unfortunately deficient under Linux. Tomorrow I will write to Mr. Moyer to thank him for at least trying. I have no intention of returning my ShuttleProv2 for another correction attempt. Even without the 0000014 and 0000015 buttons under the Linux standard driver, this device is too useful for me to do without it again for 10 days. |
|
Pierre, about correctly stopping the video flow: I do not think so, but GG claimed it was working for him with usb_direct. It seems to work some times for me but not always I personally would rather make sure it stops and not use the .25 speeds. The hope is that maybe in the future it will be fixed. |
|
Phyllis I see that in the last "shuttlerc" you modified these lines: #S-1 REV_0.25 # if using usb_direct S-1 XK_KP_KP_0 S0 XK_KP_KP_0 # hid_generic kernel driver does not generate s0 S1 XK_KP_KP_0 #S1 FWD_0.25 # if using usb_direct Does this mean that if usb_direct is used (and positions S-1 and S1 are changed to 0.25), position S0 XK_KP_0 can now correctly stop the video flow, even if the Shuttel has not been modified by the company? |
|
Pierre: checking the mixer problem with shuttle "wheel" I have not been able to reproduce the problem. All of the mixer windows updated for me in both forward and reverse when I had 6 up and my insertion point is in the main window to play but it is slow. I did try highlighting different ones of the Mixer Viewers at any time and then back to play in the main window. And I have "Click to Play" enabled in the Compositor and use the shuttle wheel there and that is working too. I will keep trying different things to see if I can get a failure (because this is kind of just fun). Other Updates: 1) Contour Design seems willing to manually fix a ShuttleProv2 that has the button 14 and 15 problem and seems to be willing to generate a Shipping Label to do so. We opted not to do so since USB_Direct solves the issue anyway. 2) Adding this note here in case the Shuttle changes in the future -- so GG does not have to "re-invent the wheel" (pun intended). From a Sept. 15, 2016 Amazon review: "Turns out there's a serious design bug in the Contour. It reports dial motions to the host computer as "relative" events, i.e., that the dial has been turned this many clicks clockwise or counterclockwise, while the actual reports are "absolute" events, i.e., dial positions from 0 through 255. This means that every 256 clicks of the dial, the Contour will report position "0", which the Linux kernel HID driver interprets as no motion and correctly drops the event. Application software doesn't see it. This can be pretty subtle; it works fine for 255 clicks, nothing happens on the 256th, and then it jumps two positions on the 257th. The bigger problem is that this bug also applies to the spring-loaded shuttle knob. As you turn it to the right, it sends "1", "2", "3" and up to "7" as you keep turning it. When you release it, it sends "6", "5" and so on. Turning it to the left produces negative numbers. So far so good, but when it sends "0" to indicate that it has returned to the center position, again the kernel driver drops it as a relative event in which nothing seems to have changed. So your software continues to see either +1 or -1. It is possible to work around this by patching the kernel driver, but this sort of thing simply shouldn't be necessary..." |
|
I meant the Shuttle... the problem is with the Shuttle. | |
In multiscreen mode, only the image of the mixer-1 reacts to the jog controls, for all speeds other than the first (slowest), whether forward or reverse. The jog and play buttons, on the other hand, activate all images of the mixers correctly. With sources in DV.avi non-proxy. |
|
Pierre: about "the Jog takes 2, and it is only at the 3rd click that you see the image change, whereas you only need 2 with the keys of the keyboard". When I carefully control the jog dial, it seems to work correctly on our newest shuttle and the shuttle Xpress. However, if I am clumsy and do not get to a solid point when I jog, then sometimes it does not go to the next frame as expected. I have also found that initially when I start Cinelerra, if I jog first, then it might miss but if I wheel forward and backward to sort of wake things up, it seems to work consistently from then on. So I think it is as good as it is going to get because I have never been able to get a reproducible failure for GG to analyze. MatN: about "the missing libusb-1.0-0-dev -- should not the blds/bld_prepare.sh and configure scripts be adapted to make sure this is installed?" This is now complete so thanks for the reminder. |
|
The "problem of latency and hesitation in the fast alternations of the Jog" seems less pronounced to me than before; it no longer seems visible under the Viewer and, in the Compositor, it is still there, but you have to turn the Jog faster and longer to see it appear during the inversion. I have not used paper labels until now. Because on the one hand, those with logos do not seem appropriate for the functions we have chosen and, on the other hand, I did not want to write on the blank ones, until I have made my final personal choice of the functions as I will use them here after a longer trial period. We'll see, at that point I'll know the functions of all the buttons by heart, that's for sure and only the prospect of letting someone else do the editing on my system, would perhaps justify the labels. The third reason... is that half of the buttons do not offer label support. This is not very coherent and consistent on the part of CONTOUR. |
|
Pierre: The latest checkin and build has the shuttlerc changed (but USB_DIRECT still commented out; so have to uncomment for K14/K15). And I changed: K1 "l" # Add label at position (useful in all modes[Viewer]/[Compose]/[Cinelerra]) K4 "i" # Clip And when a good idea comes up for K2/K3 will change then. Now just marked as mouse button 1 and 3 so easy to spot for future use. Also, marked K10 and K11 in the Viewer with mouse button 1 and button 3 so easy to replace if the new issue 138 I opened gets completed. I see no solution for the "problem of latency and hesitation in the fast alternations of the Jog". GG says it has to execute more code so is going to be slower. Maybe some idea will be thought up later. Do you use the paper labels that came with the ShuttlePro? I can not decide if they are a good idea or which just come loose? |
|
Pierre: I am waiting until business hours on Monday to send email and information to Contour about: "firmware problem of the electronic circuits" possibility. And GG thinks it would require reburning (by that I think he means what you said of updating the firmware). We will have to wait and see if CONTOUR comes back with any suggestions. We may have to live with the "problem of latency and hesitation in the fast alternations, of the Jog". I do not know yet. GG is still working the playback/speed/lock problems, but I do not think that it is related. I will look at your Key suggestions. K1-K4 just got assigned the way the did as I just made them up and do not think currently they are all that practical. K10 and K11 of the new option may not be all that easy but I will ask. |
|
Is it possible that the bugs in the K14 and K15 buttons (not correctly sending a "done") of the new ShuttlePRO v2, are actually a firmware problem of the electronic circuits of these shuttles, which could be fixed by an update of the firmware by their manufacturer CONTOUR? It's nice to see K14 and K15 working... As for the other buttons, here are my suggestions: As for the reappropriation of K10 and K11 in the VIEWER, if it were possible, I would rather entrust them with the two-way presentation of the different sequences (white) already used in the source in the Viewer (I know that this would be a new option). For the top row of buttons, I think we could reassign differently K1 "i" # Clip K2 "x" # Cut K3 "c" # Copy Copy K4 "v" # Paste Cut, Copy and Paste are used everywhere in computing and their keyboard shortcuts are well known, it is not necessary to assign them K2, K3 and K4. Instead, I propose to attribute to K1 "l" # Add label at position (useful in all modes[Viewer]/[Compose]/[Cinelerra]) K4 "i" # Clip And to wait until we have a good idea for the allocation of K2 and K3 (maybe reserve them for work on Keyframes?). The problem of the Jog, in the Viewer, which instantly passed from the first frame to the last frame of a segment, is solved. On the other hand, the problem of latency and hesitation in the fast alternations, of the Jog, is still present. Translated with www.DeepL.com/Translator |
|
Pierre: the 2.0 version of the ShuttlePro was not correctly sending a "done" for K14 and K15. GG has been able to directly code the USB method since he has complete control over that. The alternative of using the linux hid driver would take months (if ever) to get the various distros to implement in the kernel. Another new Mint 18 is available at BUT it has an UNDO (z shortcut) problem: https://www.cinelerra-gg.org/download/testing/cinelerra-5.1-mint18-x86_64-static.txz 1) You will have to make sure to remove the # in front of USB_DIRECT in your shuttlerc file. There is a new one in the cinelerra path that has K14 and K15 as [ and ]. And K10/K11 in the Viewer are redefined as loop play and add label. 2) Please verify that your /etc/udev//etc/udev/rules.d/99-ShuttlePro.rules contains all of these lines: ATTRS{name}=="Contour Design ShuttlePRO v2" MODE="0644" ATTRS{name}=="Contour Design ShuttleXpress" MODE="0644" ATTRS{name}=="Contour Design ShuttlePro" MODE="0644" SUBSYSTEMS=="usb", ATTRS{idVendor}=="0b33", ATTRS{idProduct}=="0020", MODE="0666" SUBSYSTEMS=="usb", ATTRS{idVendor}=="0b33", ATTRS{idProduct}=="0030", MODE="0666" 3) You will have to stop cinelerra, and unplug the ShuttlePro, and plug in again before starting cinelerra. If not working right away, try unplugging a couple of times. A fix for the bug you found earlier in the Viewer where if you turn the Jog forward, it immediately jumps to the end image of the segment is included. I hope I did not forget anything. |
|
MatN: "missing libusb-1.0-0-dev" - we will get a resolution for this by the end of the month. The Direct USB code, which used libusb, was written to help determine the difference between 1.7 and 2.0 of our older shuttlePro and Pierre's newer one. But it did not help. Pierre: "if I turn the Jog forward, it immediately jumps to the end image of the segment" - you found a bug that is not just the jog, but the first single frame forward key pad 1, jumps to the end also. Have duplicated here so can work on fixing that. GOOD NEWS here. A new model shuttle pro arrived here and has the exact same problems Pierre already has noted and we have been trying to diagnose long distance. |
|
From the latest version of CinGG (2019-02-15 05:38) Good news, it no longer crashes in search mode for the source segments used. New problem.... If I select a white segment (when searching for the source segments used), this segment is found in the Viewer at the position of its beginning image. But if I turn the Jog forward, it immediately jumps to the end image of the segment and continues from that point. If I turn the jog backwards instead, the first frame displayed is the one at the end of the segment and the next... returns to the beginning of the segment and then moves back from that point. These problems are not present in the case of the Compositor. In addition, I would like to point out that the latency problem (already reported) at the jog level creates significant hesitations in the event of rapid transitions between forward and reverse scrolling. |
|
The current git (20190215T0905 UTC) cannot do a debug build, because of the missing libusb-1.0-0-dev (as documented below by Phyliis: https://www.cinelerra-gg.org/bugtracker/view.php?id=124#c855). Because this is now a supported product, should not the blds/bld_prepare.sh and configure scripts be adapted to make sure this is installed? | |
I think it is very good now so will leave it at that until the new shuttle arrives here and we can determine what is wrong with K14 and K15. It can still be changed if later Sam, Andrea, or IgorB think it needs further refinement. I will fix the documentation to reflect this now. | |
I compared your shuttlerc and mine. There is nothing else to change, the only difference left, is you who are right. In [Cinelerra] mode you gave K7 the command: K7 XK_KP_0 # Stop While I had written: K7 "f" # Go in or out of Fullscreen mode This was a mistake on my part; "f" is not operating on the Timeline. |
|
I have made the last 2 changes for K12 and K13 in the Viewer here locally and will go over the shuttlerc-2 file you added in your earlier note. The dial single frame problem you mentioned awhile back is still giving me trouble. I see the same problem going forward as reverse BUT I am only using the Xpress right now as GG works with the Pro to solve more issues. |
|
Hi Phyllis, In the latest version of CinGG, you have integrated my suggestions into the shuttlec file, but I think there is a small error. In the section,[Viewer] we find now: K12 Alt-XK_Left # Go to previous edit K13 Alt-XK_Right # Go to next edit But in the Viewer there are no clips as in the Composer, so these two buttons do not cause any reaction. I think the configuration should rather be (as in[Cinelerra] and[Composer]): K12 Ctrl-XK_Left # Go to previous label K13 Ctrl-XK_Right # Go to next label |
|
Phyllis, you put a lot of responsibility on me for choosing the right button configuration.... On someone who had never had a shuttle that worked before... I understand that I may be the only one in the group that has one right now, but I would like to hear from Sam, Igor, Andrea and other experienced users about their configuration preferences if they get one eventually. For the moment I'm just trying to evaluate how these controllers could be the most useful. For me it is very clear that these are not variants of mice. They should not seek to replace what a mice can do. Shuttles are complementary and seem to me to be particularly suitable for facilitating the targeted movement of viewing in sources and timelines. The buttons should therefore offer the most useful and frequently used travel shortcuts. The extra buttons can offer commands related to the objectives of the movement in the material. I also think that we should try to group the buttons into clusters by related functions... I don't quite understand what you're proposing by "K7 also "f' for main window for "fit time display to selection" instead of Stop as is currently?" K7 "f" for[Viewer] and[Compose] seems very useful to me at the moment. Is it for[Cinelerra] that you propose another function? I don't understand what "fit time display to selection" means. As for the default configuration... I'm not in favor of functions that vary according to the context[Viewer]/[Compose]/[Cinelerra]. At the moment only K10 and K11 are different in the Viewer and this will be fixed if it is possible to make K14 and K15 functional. The Shuttel buttons are not equipped with context menus. A user who only occasionally uses CinGG and a Shuttle would have great difficulty remembering the different variable functions of the buttons. I think that the functions that vary according to the context are for advanced users who will use them very regularly. It is the latter who are also the most likely to take the time to create a custom configuration file, to their liking, which will probably be very different from anything that could be present by default. For K6 and K8, I find it very useful to be able to obtain normal forward and reverse speeds, without having to hold the Shuttel in a precise and precarious position. For me, the Shuttel ring is something to be handled quickly, at variable speeds, to search for useful precise passages. Slow motion is not a mode I usually leave running for a long time, I use it quickly, from front and back, to find a specific point (especially in the sound). It can therefore only be accessed by the Shuttle. I think K14 and K15 are ideal for"[" and"]". These commands are the fundamental role of the Viewer and it is with the Viewer that Shuttel will be most useful. If these keys are assigned a different function in the other modes, they must be similar. We misunderstood each other... I am in favour of K12 and K13 being identical in all modes, it is possible to make "l" marks in all modes[Viewer]/[Compose]/[Cinelerra]: K12 Ctrl-XK_Left # Next mark "l" on the left K13 Ctrl-XK_Right # Next mark "l" on the right Let's try to prepare the most useful default configurations, but I wouldn't be surprised at all, that when there are more user feedback, more useful suggestions lead to a revision of the default preferences... I attach my .shuttlerc file (which includes my small modifications) in case it would be useful.
shuttlerc-2 (3,572 bytes)
# uncomment to enable diagnostics #DEBUG # uncommet to use direct usb #USB_DIRECT # redefine default, use # also used for resources,load windows [Default] [Resources] [Load] K5 XK_Home K6 XK_Button_1 K7 XK_Button_2 K8 XK_Button_3 K9 XK_End JL XK_Scroll_Up JR XK_Scroll_Down [Cinelerra] # Most useful functions have to be on K5-K9 because Xpress only has 5 keys K5 XK_Home # Beginning K6 XK_KP_6 # Reverse, of if playing Stop K7 "f" # Go in or out of Fullscreen mode K8 XK_KP_3 # Play, or if playing Stop K9 XK_End # End # K10 "[" # Switch if K14 not working # K11 "]" # Switch if K15 not working K10 Alt-XK_Left K11 Alt-XK_Right # K12 XK_Home # Beginning # K13 XK_End # End K12 Ctrl-XK_Left # Prochaine marque "l" à gauche K13 Ctrl-XK_Right # Prochaine marque "l" à droite K14 "[" # Toggle in K15 "]" # Toggle out K1 "i" # Clip K2 "x" # Cut K3 "c" # Copy K4 "v" # Paste S-7 REV_16 # Next 6 are reverse keys S-6 REV_8 # the number on the end represents speed S-5 REV_4 # number can be decimal up to 64 S-4 REV_2 # 2 means 2x or double speed S-3 REV_1 S-2 REV_0.5 # note 0.5 represents 1/2 speed S-1 XK_KP_0 # Because the Shuttle does not generate S0, have to use S1 S0 XK_KP_0 # Hardware does not generate S0 S1 XK_KP_0 # Because the Shuttle does not generate S0, have to use S1 S2 FWD_0.5 # Next 6 are forward keys S3 FWD_1 S4 FWD_2 S5 FWD_4 S6 FWD_8 S7 FWD_16 JL XK_KP_4 # Frame reverse JR XK_KP_1 # Frame forward [Composer] # Most useful functions have to be on K5-K9 because Xpress only has 5 keys K5 XK_Home # Beginning K6 XK_KP_6 # Reverse, of if playing Stop K7 "f" # Go in or out of Fullscreen mode K8 XK_KP_3 # Play, or if playing Stop K9 XK_End # End # K10 "[" # Switch if K14 not working # K11 "]" # Switch if K15 not working K10 Alt-XK_Left K11 Alt-XK_Right # K12 XK_Home # Beginning # K13 XK_End # End K12 Ctrl-XK_Left # Prochaine marque "l" à gauche K13 Ctrl-XK_Right # Prochaine marque "l" à droite K14 "[" # Toggle in K15 "]" # Toggle out K1 "i" # Clip K2 "x" # Cut K3 "c" # Copy K4 "v" # Paste S-7 REV_16 S-6 REV_8 S-5 REV_4 S-4 REV_2 S-3 REV_1 S-2 REV_0.5 S-1 XK_KP_0 # Because the Shuttle does not generate S0, have to use S1 S0 XK_KP_0 # Hardware does not generate S0 S1 XK_KP_0 # Because the Shuttle does not generate S0, have to use S1 S2 FWD_0.5 S3 FWD_1 S4 FWD_2 S5 FWD_4 S6 FWD_8 S7 FWD_16 JL XK_KP_4 # Frame reverse JR XK_KP_1 # Frame forward [Viewer] # Most useful functions have to be on K6-K9 because Xpress only has 5 keys K5 XK_Home # Beginning K6 XK_KP_6 # Reverse, of if playing Stop K7 "f" # Go in or out of Fullscreen mode K8 XK_KP_3 # Play, or if playing Stop K9 XK_End # End K10 "[" # Temporary until K14 Pro fixed K11 "]" # Temporary until K15 Pro fixed # K12 XK_Home # Beginning # K13 XK_End # End K12 Ctrl-XK_Left # Prochaine marque "l" à gauche K13 Ctrl-XK_Right # Prochaine marque "l" à droite K14 "[" # Toggle in K15 "]" # Toggle out K1 "i" # Clip K2 "v" # Splice K3 "c" # Copy K4 "b" # Overwrite S-7 REV_16 S-6 REV_8 S-5 REV_4 S-4 REV_2 S-3 REV_1 S-2 REV_0.5 S-1 XK_KP_0 # Because the Shuttle does not generate S0, have to use S1 S0 XK_KP_0 # Hardware does not generate S0 S1 XK_KP_0 # Because the Shuttle does not generate S0, have to use S1 S2 FWD_0.5 S3 FWD_1 S4 FWD_2 S5 FWD_4 S6 FWD_8 S7 FWD_16 JL XK_KP_4 # Frame reverse JR XK_KP_1 # Frame forward |
|
Pierre: I am relying on you to tell me what the keys should be from the view of a user instead of my just testing. My biggest concern is to make sure K5-K9 are the most useful. So we agree that K5, K7, and K9 are good. But what do you think about K7 also "f' for main window for "fit time display to selection" instead of Stop as is currently? Or? What would then be best for K6 and K8? since like you said you can already use the shuttle wheel for play/reverse? What do you think is the most important action if you only have the Xpress? K6 = [ and k8 = ] for toggle in/out? or previous and next edit? GOOD K10 Alt-XK_Left # previous edit GOOD K11 Alt-XK_Right # next edit GOOD K12 Ctrl-XK_Left # previous label GOOD K13 Ctrl-XK_Right # next label ??? K14 "[" # Toggle in # or is this function more important so that you want them on K6 ? ??? K15 "]" # Toggle out # or is this function more important so that you want it on K8 ? I am not quite sure about your statement below for the Viewer though. Why not have K12 and K13 also go to the "l" marks? K10 "[" # Temporary until K14 Pro fixed K11 "]" # Temporary until K15 Pro fixed K12 XK_Home # Beginning K13 XK_End # End K14 "[" # Toggle in K15 "]" # Toggle out But which is actually only useful in the [Viewer] section where it is already.... |
|
I don't know what happened to the previous attempt... Phyllis, In use, I find that your choice of K5 XK_Home # Beginning K9 XK_End # End Very good. It was not really necessary to have the slowdowns on this row of buttons, since they are immediately available by the Shuttle at the first positions. On the other hand, I find it a real waste of the K12 and K13 buttons to double what is now assumed by K5 and K9. Why not use K12 and K13 instead now, to go directly to the "l" marks in both directions. Type of action that will be consistent with what is entrusted to K10 and K11. |
|
Phyllis, In use, I find that your choice of K5 XK_Home # Beginning K9 XK_End # End Very good. It was not really necessary to have the slowdowns on this row of buttons, since they are immediately available by the Shuttle at the first positions.Phyllis, In use, I find that your choice of K5 XK_Home # Beginning K9 XK_End # End Very good. It was not really necessary to have the slowdowns on this row of buttons, since they are immediately available by the Shuttle at the first positions. On the other hand, I find it a real waste of the K12 and K13 buttons to double what is now assumed by K5 and K9. Why not use K12 and K13 instead now, to go directly to the "l" marks in both directions. Type of action that will be consistent with what is entrusted to K10 and K11. On the other hand, I find it a real waste of the K12 and K13 buttons to double what is now assumed by K5 and K9. Why not use K12 and K13 instead now, to go directly to the "l" marks in both directions. Type of action that will be consistent with what is entrusted to K10 and K11. |
|
Hi Phyllis, I like what you have configured for the [Cinelerra] section: # K10 "[" # Switch if K14 not working # K11 "]" # Switch if K15 not working K10 Alt-XK_Left K11 Alt-XK_Right K12 XK_Home # Beginning K13 XK_End # End K14 "[" # Toggle in K15 "]" # Toggle out I think we should find the same thing in the [Compose] section Rather than what's in it right now: K10 "[" # Temporary until K14 Pro fixed K11 "]" # Temporary until K15 Pro fixed K12 XK_Home # Beginning K13 XK_End # End K14 "[" # Toggle in K15 "]" # Toggle out But which is actually only useful in the [Viewer] section where it is already.... |
|
Curious, I wrote "K7 XK_KP_0 # Stop" When it should be "K7 "f" # Go in or out of Fullscreen mode" (as you also wrote) For a result of K5 XK_Home # Beginning K6 XK_KP_6 # Reverse, of if playing Stop K7 "f" # Go in or out of Fullscreen mode K8 XK_KP_3 # Play, or if playing Stop K9 XK_End # End |
|
I don't know if it's related to the patch so that the image really stops with the Shuttel... but the Jog takes 1 "frame" (click) too much to reverse the movement of the image. I know that you need to move a "frame" to reverse the cursor and be able to read the next frame, but the Jog takes 2, and it is only at the 3rd click that you see the image change, whereas you only need 2 with the keys of the keyboard. |
|
That makes more sense and I will change it next time as well as K10 and K11 will go to [ and ] if when the 2.0 shuttle arrives here and there is still problems getting K14 and K15 to work | |
Hi Phyllis, I understand your choice for the ShuttleXpress (although for me I prefer what I proposed) Your current choice: K5 XK_Home # Beginning K6 XK_KP_3 # Play, or if playing Stop K7 XK_KP_0 # Stop K8 XK_KP_6 # Reverse, or if playing Stop K9 XK_End # End There is an inversion error in KP_3 and KP_6 that makes the use non-intuitive. The following choice would be more useful and intuitive: K5 XK_Home # Beginning K8 XK_KP_6 # Reverse, or if playing Stop K7 XK_KP_0 # Stop K6 XK_KP_3 # Play, or if playing Stop K9 XK_End # End |
|
If I were sure that both buttons were defective, I would quickly demand a replacement functional Shuttel (either from Amazon or directly from Contour Design). I'm not sure how long I'd have to get an exchange. But.... under Windows10 with VLC, these two buttons seem to work (they change the format of the image if I remember correctly). |
|
Yes, you can delete those 2 files. I am glad the Stop is working better now! GG says he still thinks your 2 keys may really be broken, but we will see when our new one arrives. There are some other key assignment differences also. The K10 and K11 in the Cinelerra window are "go to left edit" and "go to right edit" as I wanted to test those. And K5-K9 were changed in all Cin/Compositor/Viewer windows to be what I thought was most useful if using the Xpress since it only has those 5 keys. By the end of this month, we should finally have all the answers! |
|
Thank you Phyllis, my Shuttle is working again (without of course K14 and K15). If they are no longer useful, should I delete the "mint_shdmp" and "shudmp" files that are still in my user directory? I note that the modifications that GG has made to eliminate the movements that did not stop with the Shuttle, seem to be effective. It is a real pity that all your efforts to solve this problem have not been successful. Perhaps the contact at "Contour Design" would have some information to provide you with about the features of this new ShuttlePRO v2, if not to provide you with one... |
|
You should just have to modify your .shuttlerc file to put a # in front of USB_DIRECT near the top of the file. Or just put back your original if you saved that. Probably need to unplug it and replug it in. I should have mentioned that earlier. Let me know if still have problems. |
|
Could it be that the test failed because there are still files and configurations left in my system from previous unsuccessful attempts. At the moment my shuttle is no longer working. What would it take for me to change to make it functional again? | |
That should have worked. I will just get order from Amazon, no problem. Thanks so much for your help and patience. | |
I do the procedure three times without any results. The first time I passed the codes and realized I hadn't plugged in the Shuttle... I plugged it in... no results. Still plugged in, I did the whole procedure again, with no results. To be sure I did it a third time.... Same thing, pierre@i7-3770k ~ $ chmod +x shudmp pierre@i7-3770k ~ $ sudo ./shudmp [sudo] Mot de passe de pierre : pressing (after entering the codes), buttons K5, K14 and K15 do not cause any reaction. |
|
Just download the file and save to your current directory like you did with shdmp_mint. It does not matter where you save the file but when using it, you have to state the entire path. Then you have to make the file have the correct permissions with: chmod +x shudmp Now it should have the correct permissions and if you saved the file in your current directory you can keyin: sudo ./shudump |
|
Hi Phyllis, I don't understand what you mean by "attached file to your home directory". Do you mean my personal directory /home/pierre ? Do you mean /home ? But in this case the system refuses, telling me that I don't have the necessary permissions. |
|
When you have more time, please download the attached file to your home directory and save as shudmp Then keyin: chmod +x shudmp sudo ./shudmp (make sure the shuttle is not being used by cinelerra and plugged in) Press some K5, K14, and K15 and send the output. it should look something like: shuttle: 00 00 00 10 00 (K5 should look the same) shuttle: 00 00 00 00 00 shuttle: 00 00 00 00 20 (K14 is probably different) shuttle: 00 00 00 00 00 shuttle: 00 00 00 00 40 (K15 is probably different since it does not work there) shuttle: 00 00 00 00 00 Then use Ctrl-C to get out of the program and back to pierrei770$ We have a lot of static electricity here AND if you do too, you may have to unplug and plug back in and start over. |